Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
CursorXprop and ODBC derived cursors
Message
General information
Forum:
Visual FoxPro
Category:
Client/server
Miscellaneous
Thread ID:
00657585
Message ID:
00657631
Views:
18
This message has been marked as a message which has helped to the initial question of the thread.
Thom,

You cannot change the buffer mode that the resultant cursor has by default - it is always 3, not 1; the only change allowed is to change it to mode 5, Optimistic Table buffering. So your choice is either mode 3 or 5, and I suggest mode 5 for a lot of reasons (which is the subject of another thread.)

So, if you want to have updates occur without moving the record pointer, you will need to use TableUpdate. However, I also suggest you use mode 5 and eliminate the updating that will get sent when the pointer moves, thus leaving you in control.

I don't know what you mean by the local cursor using record level locks; the returned cursor is only available to the instance of VFP on that workstation, therefore it is opened in exclusive mode.

Hope this helps.

>To all,
>
>I've got an app that's using ODBC calls via SqlExec() against a Sql Server 7 database. I'm having problems with the return cursors in that they are doing record level locks, even though the cursor is local to the workstation. This is really screwing up my app because I've got some user input on some of the cursors, but the input is not being "registered" by the cursor unless the record pointer is moved.
>
>I've tried DBSetProp() against it, but I get an error saying something about "db_buftorow" in views.
>
>Looking at the documentation (shows you how despirate I am) I see it says the default value for the locking is "1"... no locks. When I run DbGetProp() against the cursor, I see the cursor is set to lock level 3... optimistic record lock... and I can't change it.
>
>I've tried SELECT * FROM INTO CURSOR and it STILL doesn't work.
>
>Any help?
>
>TIA,
>
>Thom C.
-Chuck Urwiler, MCSD, MCDBA
Previous
Reply
Map
View

Click here to load this message in the networking platform