relaties via een lookup anders dan anders?

[Bonte]

Zopas ontdekt dat relaties via een lookup in 7 anders werkt dan gewoonlijk of in FM6. Is daar iets aan te doen?

 

Als je bij een relatie een spatie of speciaal teken te veel plaatst is dat geen probleem, de relatie werkt toch. Bij een lookup is dat niet zo, een enter is geen probleem maar wel een spatie of ander speciaal teken. Dan werkt de relatie niet, HELP In FM6 werkt die relatie wel, een bug die ze in FM8 gaan oplossen?

[Koen Van Hulle]

Ik vermoed niet dat dit in bug is. Het is één van de zaken die ook bij de gekende conversie problemen vermeld stond.

 

FileMaker 7 is nu Unicode en bijgevolg werden de index aangepast.

In FileMaker 7 worden, in tegenstelling tot de oudere versies, ook spaties mee opgenomen in de index.

 

 

Koen

[Bonte]

Waarom is er dan geen probleem met een gewone relatie? Daar mag je spaties en speciale tekens toevoegen zoveel je wil, de relatie blijft werken. Het is maar als je de relatie gebruikt in een lookup dat die spaties problemen opleveren.

 

Ik ga wachten op versie 8 maar als het daar ook zo is ga ik voor elke relatie 2 berekende velden moeten maken als ik met een lookup wil werken of met een script een replace doen, te gek voor woorden eigenlijk.

[Koen Van Hulle]

In plaats van calculatie velden of scripts, kun je misschien de auto-enter functie gebruiken op je sleutels.

 

Als je enkel bepaalde waarden toelaat in je sleutels kun je de filter functie gebruiken.

 

Filter( veldnaam; "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ")

 

filtert alle speciale karakters uit je sleutels.

 

 

Koen

[Bonte]

Die filter lijkt me wel handig, bedankt.

 

Beide delen in de relatie zijn aanpasbaar door de gebruiker dus zal ik aan beide kanten voor verschillende relaties berekende velden moeten maken of met een replace werken, dat lijkt me praktisch gezien nog haalbaar denk ik.

 

Even de situatie schetsen, misschien hebben jullie nog gebruikerstips. Een update met extra gegevens wordt eerst gecontroleerd of de gegevens al bestaan of dat ze aangemaakt moeten worden. Dat gebeurt stuk per stuk met een controle via een relatie (onderwer-onderwerp), elk nieuw onderwerp wordt dan in de desbetreffende tabel aangemaakt. Importeren en automatisch laten aanmaken lukt niet omdat de velden letterlijk gecontroleerd worden en niet relationeel (zelfde probleem als de lookup eigenlijk) en elk nieuw gegeven mag maar 1 keer aangemaakt worden, bij het importeren worden ze allemaal aangemaakt.

[Koen Van Hulle]

Als je een validatie op een veld toepast en er bij vermeld dat dat veld uniek moet zijn en de optie Altijd (Always), staat aangevinkt, dan zullen records die niet aan de validatie voldoen niet geïmporteerd worden.

 

 

Koen

[Bonte]

Daar had ik inderdaad nog niet aan gedacht, goeie tip. Zal ik zeker kunnen gebruiken

 

Jammer genoeg niet altijd, een onderwerp kan meerdere namen hebben (bv een auteur met al z'n pseudoniemen) dus ik heb er niets beters op gevonden die namen in 1 veld te plaatsen gescheiden door een enter. Als de gebruiker dan een naam invult kan ik met een simpele relatie makkelijk zien of het al bestaat of niet, lookups en imports werken anders dus zijn niet bruikbaar.

 

Ik heb het mezelf heel moeilijk gemaakt natuurlijk, de gebruiker kan aan beide kanten van de relatie gegevens aanpassen of aanvullen en er zijn ongeveer 10 tabellen die hiervan gebruik maken. Momenteel loop ik met een script alles al met controle via relaties en maak dan telkens nieuwe zaken aan maar dat is niet bepaald een mooie of snelle oplossing.