bug report

[Jim Locker]

You’re gonna love this one. This code executes differently in Windows 2000 (and, therefore, probably XP) and in Windows 7 Pro (and, therefore, probably Vista): if rec !@= .nul e = 0; rec =@ rec.selectcurrent(idx, locktype, error = e) else e = 0: rec =@ t.select(lastrecord = .false, locktype = locktype) end if In this routine, t is a table object, rec is a record object, and locktype has the value “exclusive”. When taking the false path of this if statement, in Windows 2000 the select statement bombs with an error 908 – this in spite of the fact that we are using sbme and not ppcs. However, if the code is altered like this (which it should have been anyway…) if rec !@= .nul e = 0; rec =@ rec.selectcurrent(idx, locktype, error = e) else e = 0: rec =@ t.select(lastrecord = .false, locktype = locktype, error = e) end if it executes correctly in both operating systems and the returned error is zero. This testing was done in VMware Workstation 7 virtual machines, running on a Linux host, where Win2K and Win7 Pro were simultaneously loaded. The NTFS partition that has the development code, the database files, and all executables is a physical partition on a physical drive mounted in Win2K and shared with Win7 using Windows network drive sharing. Hence, both machines were running the same executable and data – not a copy of the same executable, but the same identical executable. Both machines are also using the same simpol environment, though that is installed separately on each machine (though I do intend to merge the two installations into one).

[Michael]

On 26/04/2010 09:21, jim wrote:
> You're gonna love this one.
>
> This code executes differently in Windows 2000 (and, therefore,
> probably XP) and in Windows 7 Pro (and, therefore, probably Vista):
>
> if rec !@= .nul
> e = 0; rec =@ rec.selectcurrent(idx, locktype, error = e)
> else
> e = 0: rec =@ t.select(lastrecord = .false, locktype = locktype)
> end if
>
> In this routine, t is a table object, rec is a record object, and
> locktype has the value "exclusive".
>
> When taking the false path of this if statement, in Windows 2000 the
> select statement bombs with an error 908 – this in spite of the fact
> that we are using sbme and not ppcs.
>
> However, if the code is altered like this (which it should have been
> anyway…)
>
> if rec !@= .nul
> e = 0; rec =@ rec.selectcurrent(idx, locktype, error = e)
> else
> e = 0: rec =@ t.select(lastrecord = .false, locktype = locktype, error
> = e)
> end if
>
> it executes correctly in both operating systems and the returned
> error is zero.

Actually, the good news is, it bombed because the error variable wasn't
passed. It wouldn't have gotten through otherwise. It is not dependent
on OS. The bad news is, that you had already locked the record somewhere
and weren't aware of it. The problem is that you don't know it is locked
here, and if you select it, this routine can't get a lock on it. I can
imagine this happening if you forget to unlock a record. At that point
the record is locked. You can check for it, but I don't know if you can
unlock it at that point, since *your* object doesn't have it locked. I
have never tested that scenario, I have to admit. I also tend to use
this kind of code to protect myself:

if rec !@= .nul
if rec.stored and rec.locktype == ""
…
end if
end if

I will try this test later today. The problem I am foreseeing here is if
an object containing a reference to a record that it has locked, goes
out of scope, then the record will remain locked, but no other method
exists to free the lock, short of closing and opening the table, since
the object that held the lock is gone. I don't know whether the lock is
released if the object goes out of scope, but it may not be.

Are you running in multiple threads? If so, you may also be ho9lding a
lock on the record in a different thread.

Ciao, Neil

[Jim Locker]

Actually, on re-reading my original message, I see that I didn't make one
thing clear.

The code runs without error on Win7 and throws the error on Win2K, given
identical run scenarios.

Also, when I do put the error statement in, the error variable contains 0
in both OS's after executing the statement.

When this happens, it is the first time that table is accessed at all. If
there is a dangling lock someplace, it is from a previous run. I
certainly wouldn't expect that to happen.

[Michael]

On 26/04/2010 19:04, jim wrote:
> Actually, on re-reading my original message, I see that I didn't make
> one thing clear.
>
> The code runs without error on Win7 and throws the error on Win2K,
> given identical run scenarios.

Hmmm. Very strange.

> Also, when I do put the error statement in, the error variable
> contains 0 in both OS's after executing the statement.

So it is returning a 0 in both cases, but it still claims there is an
error. At what point does it throw the error then, since it is returning
a 0. If the record object .nul or something else?

> When this happens, it is the first time that table is accessed at
> all. If there is a dangling lock someplace, it is from a previous
> run. I certainly wouldn't expect that to happen.

If it is the first time it is accessed, then there won't be any dangling
locks (not in SBME – in PPCS, failure to unlock will leave the record
locked until the timeout expires).

Ciao, Neil

[Jim Locker]

If you re-read my first message, you'll see two versions of the code. The
first version (incorrectly) wouldn't capture the error and would result in
the program halting if an error occurred.

In that version, running it in Win2K resulted in an error 908, while
running it in Win7 resulted in no error. After the code is corrected to
capture the error, the error returned is (quite properly) zero in both
environments.

[Michael]

On 26/04/2010 20:25, jim wrote:
> If you re-read my first message, you'll see two versions of the code.
> The first version (incorrectly) wouldn't capture the error and would
> result in the program halting if an error occurred.
>
> In that version, running it in Win2K resulted in an error 908, while
> running it in Win7 resulted in no error. After the code is
> corrected to capture the error, the error returned is (quite
> properly) zero in both environments.
>

I realize that, but my point is that SIMPOL won't return an error unless
it can't do the request. The provision of an error variable is optional,
but if the error occurs, and no error variable has been supplied (and it
must be initialized), then at that point the program will abort with an
error. So essentially what I m saying here is also back to the original,
unless the record was already locked in some way, it shouldn't have
mattered whether an error variable was passed or not. Granted, I doubt
we are testing on Windows 2000, probably only on XP and up (and Win 9x),
but still, this shouldn't matter.

Ciao, Neil

[Jim Locker]

If it does it on 2000 then it likely will do it on XP though I am not in a
position to test that.

There are three peculiarities here. First, the error was returned in one
OS but not the other, when the runtime scenarios were identical. Second,
the error returned is supposedly a PPCS only error, when PPCS is not being
used. Third, when the error return variable was specified, the error
vanished.

I have just recently encountered some other error 908 messages which I
have not yet tried to track down. So apparently 908 is not just PPCS only.

[Michael]

On 28/04/2010 01:21, jim wrote:
> If it does it on 2000 then it likely will do it on XP though I am not
> in a position to test that.
>
> There are three peculiarities here. First, the error was returned in
> one OS but not the other, when the runtime scenarios were identical.
> Second, the error returned is supposedly a PPCS only error, when PPCS
> is not being used. Third, when the error return variable was
> specified, the error vanished.
>
> I have just recently encountered some other error 908 messages which
> I have not yet tried to track down. So apparently 908 is not just
> PPCS only.

I think that is a documentation error. I have just checked the source
code and this error is returned in any case where a lock is attempted
when there is a pre-existing lock.

As for the error being returned in on OS and not another, I would need a
reliable reproducible for that one, but the key is that if you pass an
error variable, it behaves correctly.

With regard to the other errors, add a check to see if the record object
is already locked before attempting to lock it (or the table or the
sbme1 object – if you lock those). The trick with sbme is that you have
to lock the table before creating a record, so it is good to do that and
then get rid of it. I have this code specifically set throughout my
application code to check first.

Ciao, Neil

[Author]

Posts