Unanswered: Should i use Bound or unbound controls ?
i am new to databases so i would be grateful for your help.
I am using SQL Server 2000 and vb to access and update the records of a database.
I want your opinion about the way i am displaying data.
I have created a form with textboxes etc. which display the fields
of the table.
Now when i load the form i populate a recordset with a
"select ... from... " query.
It'll be cleaner if you implement your own locking to prevent users from attempting to update the data that is being updated by someone else. Relying on SQL to timeout connections that attempt to update the data being modified by another user will only frustrate your customers. With your custom locking, that can be implemented with only one table, the user can just get a message box saying that the data is being modified by another user.
In short, - don't use bound controls unless they are used for display only, like grids or reports.
That sounds very interesting. Do you know where i can find more information about custom locking ?
I use True DB Grid to update also data . Is it necessary to lock the table
each time the user opens a form that uses such a grid ?
Moreover , how is custom locking being implemented ?
Everytime the user opens a form that accesses a specific table
do i have to write in a record that this table is being accesses and then
the other users that will try to open this form will be informed that this
form/table is already being used ?
Thank you very much for your time and effort to reply to me
Usually I either do a locking by table, or, more often, by business logic. For example, I have many tab-based forms where multiple info gets displayed. Many elements on those tabs are coming from different tables. When one user clicks on Edit button, a table acquires a record with info reflecting the user's workstation, date/time, user name, and logical unit being modified. Other users when attempting to do the same receive a message that this part of information is being modified by...the elements listed above go into the message. It get a little more complex when modification of one set of info invalidates the other even though the other info is not affected. In this situation you need to think through from the business perspective what comprises a logical unit. Also, in earlier stages of development you may find yourself leaving records in that LOCK table even though users are long gone (whatever reason may be behind, - connection broken, you forgot, etc.) For that I also wrote a scheduled task that does a cleanup of entries that should not be in the table.