Skip to content

sbme locking problem?

Forums Forums SIMPOL Programming sbme locking problem?

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #251
    Jim Locker
    Member

    Consider this code segment: if rec !@= .nul and not newrec and iRtn == 0 e = 0: rec.unlock(error = e): //error will get thrown here if record is already unlocked. That’s OK; just ignore it. e = 0: rec =@ rec.selectcurrent(locktype = “exclusive”, error = e) iRtn = e end if I have an sbme file that contains one table and that table contains one record (at this time…this is a test case). This segment of code is hit at a time when I am preparing to store a modified record. I have a shared lock on the table object, no lock on the record object, and no lock on the sbme object. When this segment of code is executed, the rec.unlock throws a 903 error code, which is expected. Then the rec.selectcurrent executes, and it throws a 908 error code, which should not happen. This is a standard piece of code that is used by many parts of my system and it seems to work without any problem except on this one particular case (one table with one record). I see no evidence the file or the table or the record is corrupted, and everything seems to be OK, except for that 908 error. What could be causing this?

    #1428
    Michael
    Keymaster

    On 05/01/2014 20:23, Jim wrote:
    > Consider this code segment:
    >
    > if rec !@= .nul and not newrec and iRtn == 0
    > e = 0: rec.unlock(error = e): //error will get thrown here if record
    > is already unlocked. That's OK; just ignore it.
    > e = 0: rec =@ rec.selectcurrent(locktype = "exclusive", error = e)
    > iRtn = e
    > end if
    >
    > I have an sbme file that contains one table and that table contains one
    > record (at this time…this is a test case).
    >
    > This segment of code is hit at a time when I am preparing to store a
    > modified record.
    >
    > I have a shared lock on the table object, no lock on the record object,
    > and no lock on the sbme object.
    >
    > When this segment of code is executed, the rec.unlock throws a 903 error
    > code, which is expected. Then the rec.selectcurrent executes, and it
    > throws a 908 error code, which should not happen.
    >
    > This is a standard piece of code that is used by many parts of my system
    > and it seems to work without any problem except on this one particular
    > case (one table with one record). I see no evidence the file or the table
    > or the record is corrupted, and everything seems to be OK, except for that
    > 908 error.
    >
    > What could be causing this?
    >

    Good question. I normally don't leave table locks on except while creating records. If I need to do a big import/update, where I
    would both update and create records, I would probably just get an exclusive lock on the table, since then you don't need to lock
    the records. Saves a lot of hassle with trying to lock and checking for failing, etc.

    Try it with the table lock disabled.

    I also don't test locks this way myself. I tend to just do something like:

    if rec !@= .nul and not newrec and iRtn = 0
    if rec.locktype != ""
    e = 0 : rec.unlock(error=e)
    end if
    e = 0: rec =@ rec.selectcurrent(locktype = "exclusive", error = e)
    iRtn = e
    end if

    Ciao, Neil

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.