people at the same time, most of who are very very slow typers; and its
a customer related application where a user opens the form and asks the
customer for questions as he or she types in the details; plus most
users are not computer literate
Problem is - a lot more code has to be written meaning more space for
bugs to creep in.
Vahan Yoghoudjian wrote:
> I like Jangita's method
>
> no really need to lock a record just because the user has started inputing
> data, which may take couple of seconds or 15 minutes until he clicks OK or
> Cancel... As he suggested, fetch the data, let your application offer the
> possibility to the user to modify this data and once clicked on OK do the
> updating job using stored procedures.
>
> marking the modified fields is even a better and more solid solution but
> need a good maintenance. For example 2 users on 2 different machines
> modifying the same record will have the following statements executed
>
> User 1:
> Update clients
> set Phone = 12312312
> where clientID = '100'
>
> User 2:
> Update clients
> Set Mobile = 3452354
> where ClientID = '100'
>
> This way you will know that only one field is overriden and not the whole
> record
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED] Behalf
> Of Jangita
> Sent: Thursday, April 27, 2006 12:57 PM
> To: [email protected]
> Subject: Re: [delphi-en] Using the TTable Edit Error Event
>
>
> Hello Tom,
>
> Using this method; you *rearly* get record lock errors because as the
> user is editing the record on his form the actual database record is not
> actually locked; because i've pulled the data from the record using a
> select and thrown it into my editing components.
>
> On the instant when the user clicks the post button is where everything
> happens; for mission critical applications i change the tag of each edit
> control when the data is changed so i know exactly which fields to post
> into the database - this prevents one user changing then another user's
> data overwriting it.
>
> A simple way would be to do your own locking; adding a fiend called
> edit_stat which is normally 0 but changes to 1 when a user is editing
> the record. When another user hits edit and the field is 1 it could deny
> editing to avoid a deadlock.
>
> I have totally zero experience with nexusdb so its kind of a problem
> coming up with a solution. Any url?
>
> J
>
> Nesler, Thomas J wrote:
>> Hi Jangita!
>>
>> Your post does help me organize my thoughts. If I understand you
>> correctly, you don't use Dbaware components but when a user clicks a
>> button you fetch the data and fill the form with it or Post the changes
>> to the record. What code do you use to determine if a record is locked
>> for editing?
>>
>> What I am looking for is an example or two on how to handle deadlocks or
>> other kinds of locks on a record.
>>
>> Tom Nesler
>>
>> Live long!... Code Well!... and Prosper!... V
>>
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[EMAIL PROTECTED] On
>> Behalf Of jangita
>> Sent: Wednesday, April 26, 2006 3:50 PM
>> To: [email protected]
>> Subject: Re: [delphi-en] Using the TTable Edit Error Event
>>
>>
>> Hello
>>
>> I have done quite a bit of multi user client server programming and the
>> following is a method i have found that works best
>>
>> 1. when the user wants a list of items; i call a select stored procedure
>>
>> which returns the information; this is stored in a normal query
>> component
>> 2. i *never* use data aware components; when the user clicks edit i fill
>> the
>> components manualy with what has come from the database.
>> 3. when the user clicks save, i call another stored procedure which
>> updates
>> the specified record
>>
>> This avoids me having to keep any record in "edit" mode at all, leaving
>> other users able to browse and modify such records. To make it more
>> effecient ud probaby only update the field that has been changed, but
>> that's
>> another story.
>>
>> Hope any of this is relevant...
>>
>> J
>> ----- Original Message -----
>> From: "Nesler, Thomas J" <[EMAIL PROTECTED]>
>> To: <[email protected]>
>> Sent: Wednesday, April 26, 2006 7:15 PM
>> Subject: RE: [delphi-en] Using the TTable Edit Error Event
>>
>>
>>> Hi Bob!
>>>
>>> I am using NexusDb version 1.08 and it does give me an error when a
>>> record is locked. Unfortunately it does not resolve the conflict by
>>> preventing the second user from editing the record. Which means that
>>> the first user can't exit the record and post because the second user
>> is
>>> still editing the record.
>>>
>>> I am guessing that this is a problem that is tied to the Blob Memo
>> that
>>> the user is trying to edit. Since Blob memos are handled differently
>>> than regular records, I am thinking that is why I am getting these
>> ugly
>>> error messages.
>>>
>>> What do you suggest?
>>>
>>> Tom Nesler
>>>
>>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[EMAIL PROTECTED] On
>>> Behalf Of [EMAIL PROTECTED]
>>> Sent: Wednesday, April 26, 2006 11:00 AM
>>> To: [email protected]
>>> Subject: Re: [delphi-en] Using the TTable Edit Error Event
>>>
>>>
>>> Hi Thomas,
>>> as usual "it depends".
>>> Which Database do you use? A "normal" SQL Client / Server RDB (as
>>> Firebird or Interbase) is able to handle that automatically.
>>> So, which Delphi version and which DB you are talking about.
>>>
>>> Have fun
>>> Bob
>>>
>>>
>>>> I am working on a multiuser application. One of my problems is
>>> record
>>>> locking, specifically when one user is editing a blob field and
>>> another
>>>> is editing the same record.
>>>>
>>>> I am guessing that I need to put some code in the Edit error
>> event
>>> but
>>>> there is no example in the Delphi help file so I can only guess
>>> how to
>>>> use it correctly.
>>>>
>>>> Can some one give me an example on how to trap a record locking
>>> error
>>>> using this event? Also what do you recommend for help in
>>> understanding
>>>> the complexities of multiuser databases?
>>>>
>>>> Thanks in advance!
>>>>
>>>> Tom Nesler
>>>> Live long!... Code Well!... and Prosper!... V
>>>>
>>>>
>>>> [Non-text portions of this message have been removed]
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------
>>>> Home page: http://groups.yahoo.com/group/delphi-en/
>>>> To unsubscribe: [EMAIL PROTECTED]
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> -----------------------------------------------------
>>> Home page: http://groups.yahoo.com/group/delphi-en/
>>> To unsubscribe: [EMAIL PROTECTED]
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----------------------------------------------------
>>> Home page: http://groups.yahoo.com/group/delphi-en/
>>> To unsubscribe: [EMAIL PROTECTED]
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -----------------------------------------------------
>> Home page: http://groups.yahoo.com/group/delphi-en/
>> To unsubscribe: [EMAIL PROTECTED]
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>> -----------------------------------------------------
>> Home page: http://groups.yahoo.com/group/delphi-en/
>> To unsubscribe: [EMAIL PROTECTED]
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>
>
> -----------------------------------------------------
> Home page: http://groups.yahoo.com/group/delphi-en/
> To unsubscribe: [EMAIL PROTECTED]
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
> -----------------------------------------------------
> Home page: http://groups.yahoo.com/group/delphi-en/
> To unsubscribe: [EMAIL PROTECTED]
> Yahoo! Groups Links
>
>
>
>
>
>
>
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
SPONSORED LINKS
| C programming language | Computer programming languages | Java programming language |
| The c programming language | C programming language | Concept of programming language |
YAHOO! GROUPS LINKS
- Visit your group "delphi-en" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
