Felaktig exekvering av NAT?

[petpee]

Hej, Jag har en ordermodell i indexterminer, som exekverar direkt på morgonen givna dagar, förutsatt att vissa villkor är uppfyllda. Nu har jag noterat något extremt irriterande, det tycks som att databasen i NAT på något vis strular med att hålla ordning på exakt datum och tid? För hur kommer det sig annars att modellen i vissa fall exekverar direkt på morgonen även dagen efter att den skulle gett signal (ett av villkoren i modellen berör aktuell dag, så teoretiskt sett torde det vara omöjligt att den exekverar på fel dag, om inte källkoden för datum i NAT är fel)? Hur förhindrar jag detta skit, som kostat pengar helt i onödan ett flertal gånger? Det ska tilläggas att övriga villkor i modellen var inte uppfyllda de dagar den exekverar (däremot dagen innan), så det verkar som att i vissa lägen så "hänger" köpsignalen på något mycket märkligt vis kvar tills även dagen efter.

[Rikard Nilsson]

Det hänger på om systemklockan går exakt rätt eller inte. Vi brukar lägga till en kontroll att databastid och systemtid är samma dag för att utesluta den risken:

samma_dag=eqv(int(d),int(date()))

[petpee]

re

Hej, Vet inte vad du menar med systemtid? Klockan på datorn är det inget fel på ivartfall, den är inställd att synkroniseras automatisk med time.windows.com enligt schema.
Men, du är alltså säker på att detta villkor ska lösa det hela? Du menar att det initialt av någon anledning kan vara som så att datumet i NAT db "släpar efter något" i början av dagen, eller?

[Bertil]

Hej!
Vet inte om detta är relevant för ditt problem, men jag har råkat ut för följande om jag försöker handla 09.00:00
Om jag då lägger min order baserad på Closekurs och om det inte hunnit ske något avslut ännu så får man gårdagens avslutclose. Jag lägger därför in en kontroll så att senaste Close inte får vara lika med gårdagens avslutclose :

...
i1(
...
villkor1=Not(eqv(c,cmpref(c,1,a)))
...
)
{@A(0,)}

Med vänlig hälsning
Bertil