question understanding lock levels

[Dave Parizek]

If I create a cursor in V4RB 1.98 and do not specify a lock level, it 
will be ReadOnly by default.

That means other processes can read but not write, correct?

the term, 'readonly', refers to how other processes are affected, 
what others CAN DO.

  But 'readwrite' means other processes cannot read or write, thus 
referring to what others CANNOT DO.  It seems the 2 terms should be 
in the same space as far as CAN DO or CANNOT DO.  Like it should be 
no_lock, writes_locked, reads_and_writes_locked.  Or it should be 
read_write_ok, read_ok, neither_ok.  But mixing terms from the 2 sets 
makes it confusing.

Oh well, just semantics.

Back to my real problem:

If I set that cursor to nil, the lock should be destroyed, correct?

I seem to be having problems where the lock still exists even after 
setting mCursor = nil, has anyone else seen this?  I'm getting 363 
errors when I try and do a SQLExecute, and I have no cursors in 
existence at the point when the SQLExecute occurs, or so I think.

To end the lock, do you need to do something else besides setting the 
cursor to nil?

--Dave


-- 
_______________________________________________
Dave Parizek
Bookseller
Dave at Parizek.com