Validatie?

[Dr_Flash]

Stel, ik werk via een detacheringsbedrijf. De ene week hier, de andere week daar. Soms werk ik zelfs voor meerdere klanten binnen 1 week. Ik heb een db waar urendeclaraties per week uit moeten rollen, en dan een apart formulier per klant en per week. De combinatie week en klant is dus uniek. Nu wil ik een testveld inbouwen, een standaard tekstveld, en zodra ik dan verder wil gaan met het invoeren van de daadwerkelijke uren, dan is één van de scriptstappen "Set field [testveld];[week & klant]". In de validatie van dat testveld staat vervolgend dat waarden in dat veld alleen toelaatbaar zijn als ze uniek zijn. Maar nu blijkt dat ik gewoon meerdere identieke week-klant-combinaties kan aanmaken.... Wat zie ik over het hoofd?

[Rony Rabijns]

Wat zie ik over het hoofd?

Heb je in je script misschien een "Set Error Capture On" staan ?

[Dr_Flash]

Nee.... Zou dat helpen denk je? We gaan het proberen... Ik dacht al dat er iets was met spaties in dat veld, ook niet.

[Rony Rabijns]

Nee.... Zou dat helpen denk je? We gaan het proberen...

neen, dat zal niet helpen, integendeel. vandaar ook mijn veronderstelling.

[Dr_Flash]

Nee.... Zou dat helpen denk je? We gaan het proberen...

neen, dat zal niet helpen, integendeel. vandaar ook mijn veronderstelling.

 

Ja dat leek mij ook al inderdaad kun je niet ergens die validatie forceren in een scriptstap oid? Want dit is gewoon waardeloos.....

[Rony Rabijns]

die setfield is blijkbaar te krachtig.

ik heb even een test gedaan met een numeriek veld, en daar via setfield alfanumerieke gegevens in gepompt. dat lukt dus. dat krijg je via reguliere input niet klaar zonder foutmelding.

[Dr_Flash]

Ik ben blijkbaar ook een "straffe gast"

 

Maar ja ik kan het niet met Go to Field en Insert Text oplossen, want ik wil dat veld niet op m'n layout hebben..... En ik kan dat testveld wel definiëren als Calculated, maar Calculated fields kun je niet Validaten... Raar dat er voor zoiets eenvoudigs niet een oplossing te vinden zou zijn...

[Dr_Flash]

Ik denk dat ik het maar met een loopje probeer... gewoon record voor record langsgaan en kijken of die waarde hetzelfde is... Is natuurlijk een bagger-oplossing maar goed als het bij minder dan 500 records nog een beetje acceptabel blijft qua snelheidsverlies dan ben ik toch ook minstens de komende 8 jaar onder de pannen. Maar het is natuurlijk lapwerk, een Oplossing laat nog op zich wachten....

[Rony Rabijns]

Maar het is natuurlijk lapwerk, een Oplossing laat nog op zich wachten....

de oplossing begint waarschijnlijk met een S

[Dr_Flash]

en het zal wel eindigen met -tef danwel -ervoy

[Arnoud]

Leuk dat je die twee tef en ervoy in dezelfde volzin gebruikt!

Als je aan Stef dienkt dan weet je dat die weer een leuke relatie heeft gebruikt.

Welnu, waarom probeer je het niet langs die weg?. Dus in feite een interne relatie gebruiken om de dubbele records er uit te vissen. Ik vrees dat je toch een script nodig zult hebben om enige veldjes te setten, met name die waar tussen de relatie gelegd moet worden. Ik geeft je ook nog even mee dat je een summary die 1 of 0 kan laten sommeren, zodat je daar op kan checken in je script. Zo'n relatie is m.i. eleganter dan een loop.

Ik kan je niet garanderen dat het werkt maar 'give it a try'.

Uit eigen ervaring kan ik je zeggen dat alle andere pakketten die ik gebuikt heb en nog gebruik, allen zo hun eigenaardigheden hebben. Wat met F supersimmpel is gaat met S erg ingewikkeld en omgekeerd. Hier krijg je wat daar laat je wat.

[Arnoud]

Nog even dit Roeland,

Waarom niet gewoon een scriptje gemaakt met een zoek en een status foundcount >=1.

Uiteraard eerst de waarde van cWeekKlant in gWeekKlant stoppen.

Ter geruststelling in S. is dat ook de meest voor de hand liggende oplossing.

Ter meerdere geruststelling: bij een grote DB zal F sneller zijn!

Alleen heb je in S. geen plugin nodig om het validatiescriptje te triggeren!

Ik zei het al, geven en nemen!

 

gr.

 

Arnoud

[Dr_Flash]

Dank je, Arnoud Je eerste optie, dat relationele verhaal, begrijp ik niet helemaal, maar met de tweede zal ik eens aan de gang gaan. Lijkt me eenvoudiger dat een interne relatie. Ik had eigenlijk het hele validatie-gebeuren al een beetje op de lange baan geschoven (er zitten in dit project nog veel meer lastige uitdagingen), maar met dat zoekscriptje gaat het waarschijnlijk wel lukken

[AvD]

Je kan zelf een validatie maken op het uniek-zijn van de combinatie klant-week door op dat veld een SelfJoin te baseren. Daarop zet je een Count. In het (nieuw te maken) controle-veld ga je na wat het resultaat van die Count is: groter dan 1, "Aaaalaarm!", gelijk aan 1 "". Die warning-tekst kan je als een merge field in het rood op je scherm laten verschijnen en je kan er ook voor zorgen dat zolang die warning-tekst er staat, geen verdere actie mogelijk is.

 

HTH

[Arnoud]

AvD schreef:

Je kan zelf een validatie maken op het uniek-zijn van de combinatie klant-week door op dat veld een SelfJoin te baseren. Daarop zet je een Count. In het (nieuw te maken) controle-veld ga je na wat het resultaat van die Count is: groter dan 1, "Aaaalaarm!", gelijk aan 1 "". Die warning-tekst kan je als een merge field in het rood op je scherm laten verschijnen en je kan er ook voor zorgen dat zolang die warning-tekst er staat, geen verdere actie mogelijk is.

 

Bij mij werkt dat niet (zo eenvoudig). De interne relatie kan niet gemaakt worden omdat het (calculatie)veld niet kan worden geindexeerd.

[Rony Rabijns]

AvD schreef:

Je kan zelf een validatie maken op het uniek-zijn van de combinatie klant-week door op dat veld een SelfJoin te baseren. Daarop zet je een Count. In het (nieuw te maken) controle-veld ga je na wat het resultaat van die Count is: groter dan 1, "Aaaalaarm!", gelijk aan 1 "". Die warning-tekst kan je als een merge field in het rood op je scherm laten verschijnen en je kan er ook voor zorgen dat zolang die warning-tekst er staat, geen verdere actie mogelijk is.

 

Bij mij werkt dat niet (zo eenvoudig). De interne relatie kan niet gemaakt worden omdat het (calculatie)veld niet kan worden geindexeerd.

vreemd, want dat calculatieveld is toch maar een concatenate van week en klant, twee velden die door Dr. Flash worden ingevoerd, en bijgevolg indexeerbaar ?!

[Dr_Flash]

Ik denk niet dat "week = indexeerbaar" + "Klant = indexeerbaar" => "WeekKlant moet dus indexeerbaar zijn" een geldige redenatie is. Volgens mij vervalt de indexeerbaarheid (indicabiliteit?) zodra je gaat Calculaten. Heel lastig. In Excel heb je zoiets in een vloek en een zucht gedaan... En daar ben ik al eens eerder tegenaan gelopen....

[Rony Rabijns]

Ik denk niet dat "week = indexeerbaar" + "Klant = indexeerbaar" => "WeekKlant moet dus indexeerbaar zijn" een geldige redenatie is.

 

tuurlijk wel, anders eet ik mijn schoenen op ...

Volgens mij vervalt de indexeerbaarheid (indicabiliteit?) zodra je gaat Calculaten.

niet altijd, maar bvb wel van zodra één van de velden een berekening is of uit een relatie komt.

 

zal ik al mijn schoenen beginnen ?

[Dr_Flash]

Smakelijk Rony! Zout en peper hebben?

[Rony Rabijns]

Ik denk niet dat "week = indexeerbaar" + "Klant = indexeerbaar" => "WeekKlant moet dus indexeerbaar zijn" een geldige redenatie is.

tuurlijk wel, anders eet ik mijn schoenen op ...

Smakelijk Rony! Zout en peper hebben?

ik begin er aan als je me het tegendeel kan aantonen.

je krijgt dan zelfs een stukje, ze zijn groot genoeg

[AvD]

Zijn "Klant" en "Week" dan niet indexeerbaar? Dat zijn toch vaste gegevens? Of anders de klant-ID, indien je de "Klant" relationeel toont vanuit een andere databank?

Dat moet kunnen!

[Dr_Flash]

Nou ik krijg het niet voor elkaar hoor. Als ik een keer wil TESTEN dan is alles ineens wel indexeerbaar..... we speuren verder.....

[AvD]

Izzi no possible that izzi no possible.

Zo zeiden ze me dat vroeger ook al. Dat móet kunnen. Trouwens wie de Rabijns dwingt op blote voeten te lopen, die krijgt met mij te doen. Recept is gekend: tussen de dikke Van Dale en hop. Vraag maar aan Pjotter.

Hierbij het geindexeerde bestandje. Rabijns, STOOOOOP, laat die schoenen staan. We gaan naar de Colmar. De Flash trakteert.

Indexeerbaar.fp5

[Dr_Flash]

Indexeerbaar? O okee we waren op een zijspoor beland. Toch hebben we inmiddels 3 trajecten: Validatie, Status(CurrentFoundCount) <= 1 en de SelfJoin (wat is dat in het NL trouwens? )

 

Validatie werkt blijkbaar niet omdat SetField te krachtig is

De SelfJoin zou moeten werken, want alles is volgens mij gewoon indexeerbaar

De Status(CFC) ga ik proberen denk ik. Als dat uiteindelijk werkt wil ik ook nog weleens kijken naar het SelfJoin-traject. Maar voorlopig laat ik dit verhaal (dat eigenlijk maar een heel klein stukje van mijn project is) even liggen. Ik heb namelijk nog een ander probleem met dit systeem, en dat is het volgende: Ik registreer mijn uren in een bestand "Weken" en een bestand "Dagen".

 

Nu wil ik met een script "Nieuwe week" vanuit het Weken-bestand forceren dat er een nieuw record met wat vooraf ingevulde gegevens gemaakt wordt (Weeknummer, begindatum, einddatum). Gesneden koek tot zover. MAAR: ik wil dat in datzelfde script geregeld wordt dat er in het Dagen-bestand 7 nieuwe records aangemaakt worden, dat daarin het juiste weeknummer ingevuld wordt en dat de datum voor alle dagen goed ingevuld wordt. Dat is helaas erg moeilijk, want ik krijg dat weeknummer maar niet in die nieuw aan te maken records, en derhalve de datum ook niet (de relatie ligt er al). Het moet met een extern script, okee, maar er is niet iets als een "SuperGlobal Field" waarin ik vanuit Weken het weeknummer kan plaatsen, en dat dan vanuit Dagen ge-Insert wordt

 

En TOCH moet het kunnen

[AvD]

Allez, Flash, ge moet uw tips opnieuw van buiten gaan leren: dat stond al in de 2!

 

http://www.avd-ci.be/tip002.htm

[Arnoud]

Heren Heren,

 

Als initiator van de discussie omtrent de indexeerbaarheid welke bijna de consumptie van schoeisel ten gevolge had, en die AvD zelfs heeft aangespoord een upload te plaatsen, wil ik u hierbij verzoeken mijn excuses te aanvaarden voor deze welhaast onvergeeflijke slordigheid: ik vergat namelijk de storage options juist in te stellen.