Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
TimeStamp Reprise
Message
From
14/12/1999 10:07:11
 
General information
Forum:
Visual FoxPro
Category:
Client/server
Miscellaneous
Thread ID:
00302651
Message ID:
00303335
Views:
20
John,

More info on this - here are few things I've tried/done and learned.

1 - I simplified the view and cursor (to test against each other) down to just three fields - the key - the timestamp - and one description field to change.
2- I re-verified the problem - namely that a tableupdate() on the VIEW does indeed use the thetimestamp field in its where clause - whereas a tableupdate on the cursor does not - it only uses the keyfield.
3 - I changed my SPT code to just issue a "SELECT ... " instead of calling a stored proc to get the result set - and thus elinate the possibility of the stored proc having something to do with it. Still did not work.
4 - I compared EVERY CursorGetProp property listed in the docs - and except for those that are view-specific, they are all the same.
5 - I used the same connection on both to make sure it wasn't connection related
6 - I compared the timestamp memo fields from both to make sure they were indeed equal - and they are
7 - I played with NOCPTRANS just to make sure - but it had no effect as #5 would indicate

Now - what I do notice that is very interesting, and may have something to do with it, is this: Watching SQL Server Profiler - I notice that when I tablupdate() the SPT Cursor, VFP updates through the Stored Procedure "SP_EXECUTESQL" - when I do the same thing on the view - it passes a straight "UPDATE TABLE ..." to the back-end. Why is this? Could it be the cause of the problem?

This is driving me nuts - I'm almost ready to write it off as a bug. It is, so far, the only thing that makes me regret not having used views instead of SPT. (if a solution can not be found)

Thanks for your help and I anxiously await your response.

Ken.



>Ah yes... the stored proc... Dumb question here, are you return the timestamp field to the VFP cursor? I will test this scenario myself to see if I can duplicate.
>
>
>
>>John,
>>
>>I am - I created a View in the View Designer and it works while my cursor doesn't! I'm currently trying to compare properties between the view and my SPT Cursor, but don't see anything so far. Could it have something to do with the fact that my cursor is from SQL Stored Proc - ie the actual select statement is not passed from VFP? I'm starting to look at the NOCPTRANS to see if that has something to do with it.
>>
>>Ken
>>
>>>Hi Ken...
>>>
>>>Make sure you are using the timestamp data type on SQL, not a datetime type.... I just tested this and it does work correctly...
>>>
>>>>Hi,
>>>>
>>>>I posted this originally Sat. morning, which was probably a bad idea since a lot of those weekend posts seem to get lost amid the mass of new messages most wake up to on Monday morning, so I'll try again with apologies to those who might read it twice now.
>>>>
>>>>I am using SPT cursors with SQL7. I have all working well - inserts, deletes, updates, identity columns etc. Now I want to use a wheretype of 4 on the cursor (key fields and timestamp) so I add a timestamp field to the SQL table, make sure it comes across in my cursor, add it to my updatefieldnames, set the wheretype to 4 and give it a go.
>>>>
>>>>Well - SQL Profiler confirms that the tablupdate is NOT using the timestamp field in the generated where clause - just the keyfield as if wheretype were still set to 1. So my question is this: Is there some other trick or setting, etc. that I need to employ to get this to work? I not that the timestamp field comes across in a memo field in my cursor. Is this correct?
>>>>
>>>>Thanks!
>>>>Ken
Ken B. Matson
GCom2 Solutions
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform