Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
IndexSeek ... Trap ?
Message
From
26/03/2002 08:22:03
Emanuele Bonin
EB Soluzioni Informatiche
Tezze S/B, Italy
 
 
To
26/03/2002 03:39:53
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00637120
Message ID:
00637175
Views:
19
>It's known and intended behaviour, no bug. It's primary usage is to check for existence of key during a new record insertion. If it returned .t. for your newly inserted record then you'd be doing old workarounds to check. Once you move off the record indexseek would return .t. for the newly inserted record regardless of it was row or table buffered.


I think that isn't a good behavior ... if i want to introduce a code that must be unique and i want to be proactive, i test the existance of code -'CODE1'- before inserting record, now i introduce a second code (without moving record pointer) -'CODE1'- that is the same of the first one (caused by my amnesia 8-)), i test the existance of code, indexseek return .f. ... so i insert the record ..... my primary key emit an error ..... isn't true?
bye, Emanuele!
In the beginning the Universe was created.
This has made a lot of people very angry and been widely regarded as a bad move.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform