>Well, I have to admit, I am a little surprised that the programmer has to handle the maintenance of locks on the data. I thought that one of the attractive features of an SQL system was that it took care of all that stuff for you (Even though I something told me it couldn't handle all of it).
>

It only took me a few minutes to write generic stored procedures to handle 'locking', 'unlocking' records, and checking for a lock. Of course, the record is not really locked...you just have to decide how you want to handle contention issues.

>So, it appears that it is not possible to allow a client to modify data accessed through SQL unless that client software was written specifically to access that particular data.
>

I'm not sure exactly what you mean here. If you are still referring to locking (or contention) issues, SQL server does not care who is updating a record. The last one wins, and most of the time that is fine. If you do need to prevent a process (or person) from changing a record while someone else has it locked ('checked out' would probably be a better way to think of it than 'locked'), it is not that hard to generalize some functions.

Have fun learning :),