Using Cursors in a Multi-User Environment 1

[LeonelSanchezJr]

If my application is being used by multiple users simultaneously, how can I prevent errors from occurring when two or more users try to run the same query?

I used to write my queries to temp tables, but then I was told that cursors are better. So if I use the same cursor name (let's say "CURSOR1&quot in the application being used by multiple users, would that cause a problem if they all ran the same query?

What if I have to update the cursor? I can't do that, so would I must come up with a "unique" name for the temp table and update the temp table? I've used the SYS(2015) before and I only use the third character through to the 11th for a total of 8 characters.

 

[rajeevnandanmishra]

Hi Leonelsanchezjr,
You don't have to worry about multiuser enviornment when you are using the VFP cursors. Because cursor are opened in individual application session. So, if you use the constant name like myCursor, every user will be having myCursor cursor, and data values can be changed, irrespective of each other.

 

[LeonelSanchezJr]

Okay, but I can not update the cursor; right?

So which data values are you referring to when you say they can be changed irrespective of each other.

Thank you for your time and assistance.

 

[rajeevnandanmishra]

Hi Leonelsanchezjr,
I was refering to Individual's cursor values.
And whether it is useful for you or not it depends on 'How you are updating your database?' i.e. by Using Insert/ Update SQL's/ or by Append Blank or ...

Just for more clearance, You can use cursor's simply at the place of your temporary tables. The benefits you get are:
1) No need to worry about the temporary cursor name for each user.
2) No need to check if they already exist or not.
3) No need to Delete them after use (as they automatically deleted as soon as you close them).

 

[ChrisCarroll]

Your initial solution - using sys(2015) - is fine.

You can also do this ...

Select * from elecnhhreading ;
  into table sys(2023) + "\Cursor1"
Select Cursor1   &&Cursor1 is read-write

... since sys(2023) will usually be private for every user, on their own c: drive.
With this approach, though, you have to remember to delete your cursors at some stage.

Another approach is

Select * from elecnhhreading into cursor notyetcursor1
Use dbf() again in 0 alias cursor1
Use &&close notyetcursor1
Select cursor1 &&Now it's read-write!

which at least deletes the cursors automatically when it's finished