Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
SQL ignores deleted()?
Message
From
01/09/2006 07:00:27
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Title:
SQL ignores deleted()?
Environment versions
Visual FoxPro:
VFP 7 SP1
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01150323
Message ID:
01150323
Views:
78
I've been selecting data into queries and noticed that my results have been going askew. Studying the source table(s) I noticed that there were several recs marked for deletion (i.e. not yet packed) that were getting included in the cursor.

So I added ... WHERE not DELETED("SourceTableName")... in the SQL, including the alias so the SQL was in no 2 minds about which of the source tables in the select from list I meant.

But made not a blind bit of difference. I was forced to pack the tables to get rid of the spurious results.

I must admit to having forgotten to issue "Set DELETED on" in the .Init() of the form but surely the
... WHERE not DELETED("SourceTableName")...
clause should have taken care of this?

UPDATE: I've just found the following info in the Select - SQL Help:

Be careful when using, in join conditions, functions such as DELETED( ), EOF( ), FOUND( ), RECCOUNT( ), and RECNO( ), which support an optional alias or work area. Including an alias or work area in these functions might yield unexpected results. SELECT doesn't use your work areas; it performs the equivalent of USE ... AGAIN. Single-table queries that use these functions without an optional alias or work area will return proper results. However, multiple-table queries that use these functions — even without an optional alias or work area — might return unexpected results.

So how to get round this?


Any advice?

'ppreciate it

Terry
- Whoever said that women are the weaker sex never tried to wrest the bedclothes off one in the middle of the night
- Worry is the interest you pay, in advance, for a loan that you may never need to take out.
Next
Reply
Map
View

Click here to load this message in the networking platform