- När det sedan gäller import/export av repeterade fält så uppstår ett problem - åtminstone för mig. FileMaker använder nått specialtecken för att skilja repetitionerna från varandra inom fältet och posten i import/export-filen. Problemet är att veta vilket. Vi får se om 99Macs eminente FileMaker-guru Taz har något att bidra med i frågan.
Stort tack för det berömmet Gunnar.
Just när det gäller ditt specifika problem skulle jag kanske fundera i riktning mot att lägga identiteterna i en separat tabell/DB med kundnummer som relationsattribut och visa dem i en portal istället.
Jag tycker att Gunnar har rätt i att man inte skall använda repeterade fält i det här specifika fallet utan istället skapa en separat tabell (både i ODBC-databasen där det heter tabell och i FileMaker-systemet där det heter register i FM 6 och tabell i FM 7) och visa dessa med en portal istället.
Repeterade fält kan vara superfiffiga att använda sig av i vissa situationer, ditt problem är INTE en sådan situation utan ställer till med lite bekymmer senare.
Troligen vill du tex kolla att en person får logga in i systemet med hjälp av denna information, det betyder att du måste leta i alla repetitionerna en i taget för att se om användarnamnet/lösenordet förekommer i varsitt fält i samma repetition via ett manus, vilket är bökigt och långsamt. Med en separat databas kan du använda en relation direkt och se om det användarnamnet och lösenordet förekommer, det går i jämförelse med scriptmetoden snabbt som vinden.
En annan aspekt är att du med repeterade fält sätter en fysisk gräns i ditt system på hur många logins som kan finnas per företag. Om du sätter gränsen lågt (tre repetitioner) så kanske någon fiffig användare som vill lägga till en fjärde login duplicerar din företagspost och då har du kanske samma kundnummer för två företag eller två olika kundnummer för samma företag och en massa annat gegg att hantera i form av orderhistorik, rabatter i förhållande till inköpsvolym mm inte fungerar.
Om du istället satsar stort på antalet repetitioner, tex 50 stycken så blir det inte speciellt lätt får plats med det i en layout och det kan bli svårt för en användare att se vilken rad som är vilken.
En tredje aspekt är att du kanske vill lägga till information till din login-databas senare, som tex riktigt namn, epostadress, telefonnummer, mobilnummer, fysisk adress (köttadress) rabattsats osv osv...
Av dessa skäl så är traditionen och praxis i branchen att man har en separat tabell för logins, med en relationsnyckel till företagsregistret.
(Jag brukar använda UID's, dvs unika ID's, istället för löpnummer som relationsnyckel i alla system jag bygger, lite om det har jag beskrivit på dessa adresser:
http://kurser.intelligentmammals.se/fm/tips/best_practices/index.html#Serials
http://kurser.intelligentmammals.se/fm/tips/best_practices/index.html#UID
Mina UID's består av en textsträng på 12 tecken där varje position är någon av bokstäverna A-Z och siffrorna 0-9. Exempel: FG82FGT6SXCO)
Tyvärr så har jag inte kollat vilket specialtecken som FM använder för att lagra repetitioner, men om jag skulle vilja ta reda på det skulle jag exportera ett repeterat fält och öppna textfilen i BB Edit och kollar där vilket tecken det blir mellan repetitionerna.
Men i ditt fall kanske det inte spelar roll eftersom du hämtade infon i en ODBC-databas (kanske via textfil?) och stoppade in den i FM. Då skall du köra ett script vid importen istället som hämtar lite information i taget från ODBC-databasen (textfilen) med hjälp av Troi File Plugin ( http://www.troi.com/ ). Den kan läsa fram till ett visst tecken och bearbeta en rad i taget i en textfil.
Men jag gissar att du i ODBC har en separat tabell redan eftersom repeterade fält inte existerar i andra databaser. I så fall är det lättare, det är bara att hämta användare för ett företag i taget och peta in dessa via script i dina repeterade fält genom att ställa en OBDC-fråga i taget och kolla hur många träffar du du får (eller läsa en rad i taget i filen via Troi File Plugin) och sedan via script i FM peta in ett användarnamn, login och lösen i taget i rätt ordning i repeterade fält. Du får då ha räknare som håller reda på vilken repetition du "är" på. Mycket pilligt alltså och det kan bli ett manus på en eller flera sidor.
Men om du skippar repeterade fält helt (min rekommendation) så behöver du ju istället bara från ODBC söka fram allt innehåll i tabellen för logins och skjuta in allt det i en FM-tabell(register) via importsteget i ett manus. (Förslagsvis tömmer du databasen i FM först). Eller så importerar du bara en textfil på samma sätt. Busenkelt helt enkelt och det kanske är tre eller fyra steg i ett manus.
