![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I have not seen this covered anywhere, and it may end up making a difference in my app. Suppose that two or more users are accessing a database. What sort of protection is there against race conditions? I may have some rather complicated RI rules to control access. It could be disastrous for more than one user's process to be executing certain DBC code. Are transactions and the use of access control tables in the database sufficient to protect against this? Is this the only approach that can be taken? I can see how network considerations with regard to buffering might be involved. Is this assumption correct? If so, how can the effect of these considerations be minimised on other applications? BTW, who executes the database code if the database is located on another system? Presumably, this is the client. Is this always so? Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices. |
#3
| |||
| |||
|
|
ALL code in VFP executes on the client. The server is nothing but a repository. |
|
The only real prevention you can do to limit your SP's to one user at a time is a file-based semaphor but that would be a performance KILLER if your stored procs are slow or you have heavy user load. |
|
I've never seen anyone complain about a race condition, so you may be worrying about nothing. Then, again, it's certainly possible to design code to fail as with any other programming language. <g |
![]() |
| Thread Tools | |
| Display Modes | |
| |