RS Locking Problem

Results 1 to 2 of 2

Thread: RS Locking Problem

  1. #1
    Andrew Sinning Guest

    Default RS Locking Problem

    In order to do some performance testing on my server application, I&#039;ve set up a page containing multiple frames, each frame containing the same form. There&#039;s a button in the top frame which sets off the Submit in all of the frames&#039; forms near simultaneously. (I had to turn off the session state in the application program to allow this to work).<BR><BR>Here&#039;s the problem, about half of the submits fail because a record set is locked by one of the other submits. (Microsoft OLE DB Provider for ODBC Drivers (0x80004005) [Microsoft] [ODBC Microsoft Access Driver] Could not update; currently locked by user &#039;admin&#039; on machine &#039;GATEWAY2000&#039;.) I&#039;ve tried both optimistic and pessimistic locking. How do I avoid this?<BR><BR>Perhaps I should explain what the server is doing: Each submit includes user responses to 50 questions. First, the server creates a new record in a "responseEvents" table. This results in a autoNumbered "responseEventId" {n} being created for the response set. Then, for each of the 50 questions, a new record (responseEventId={n}, questionNumber={1..50}) is created in a "questionResponses" table. It&#039;s during the process of creating the 50 new records for each of the simultaneous submits that the error occurs.<BR><BR>Can anyone offer a suggestion how I might create a more robust server? Currently I&#039;m using an Access database. Is it time to "move up" to SQL?<BR><BR>

  2. #2
    Join Date
    Dec 1969

    Default RE: RS Locking Problem

    Access locking is carried out at a file level. you should either break it up into smaller files, or upgrade to SQL Server, which locks at a much finer level.<BR><BR>of course, if you&#039;re only stress testing and don&#039;t actually expect that many users, you may be OK.<BR><BR>there are also other ways to optimise your application (like keeping connections open for the *absolute minimum* amount of time, moving code to components, using a quicker scripting language (like PerlScript or JScript - VBScript is slow in comparison), cutting down on context switches, using Access Queries instead of concatenated strings and so on.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts