Way to reveal record locks?

I am using MS Access as a front end to a postgres database running on a Sol=
aris Unix box, using odbc as the communication medium.

One of the main tools of my Access app is a process that runs at night to p=
rocess student progress in an online training system.

A couple of nights ago the app started generating the error:
"Runtime error 3046: Could not save; currently locked by another user"
and it is on the app screen when I come in in the morning, locking up the p=
rogram and keeping it from completing. I trap as many errors as I can thin=
k of, but this is escaping trap so I don't know where in the code it is hap=
pening.

I am sure that the error is not from an Access user A. because the process =
runs between 11pm and 1am and 2. because there are no .ldb files open, a fi=
le type created when a user opens an access application.

So, is there any way to determine what records are locked, if in fact that =
is the problem? (As you know, the error reported may not actually be the u=
nderlying problem).

Most of the program is designed with classes instantiated as objects, and i=
n Access when I take the 'debug' option of the error message box, all that =
happens is the program goes to the first process of the first object, so th=
at is useless.

If no one has an answer I will probably write a routine that steps through =
every record of every table and attempts to lock it to see if I can reprodu=
ce the error that way.

Thanks in advance for any suggestions anyone may offer.

Fred Parkinson


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: Way to reveal record locks?

Hi!

Fred Parkinson wrote:
> I am using MS Access as a front end to a postgres database running on a Solaris Unix box, using odbc as the communication medium.
>
> One of the main tools of my Access app is a process that runs at night to process student progress in an online training system.
>
> A couple of nights ago the app started generating the error:
> "Runtime error 3046: Could not save; currently locked by another user"
> and it is on the app screen when I come in in the morning, locking up the program and keeping it from completing. I trap as many errors as I can think of, but this is escaping trap so I don't know where in the code it is happening.
>
>
This error was not generated by PostgreSQL or ODBC driver. It belongs to
the Visual Basic runtime processor: http://www.halfile.com/vb.html.
> I am sure that the error is not from an Access user A. because the process runs between 11pm and 1am and 2. because there are no .ldb files open, a file type created when a user opens an access application.
>
How many Access users you have, may be someone accesses your data via
remote desctop or something like that?
> So, is there any way to determine what records are locked, if in fact that is the problem? (As you know, the error reported may not actually be the underlying problem).
>
> Most of the program is designed with classes instantiated as objects, and in Access when I take the 'debug' option of the error message box, all that happens is the program goes to the first process of the first object, so that is useless.
>
> If no one has an answer I will probably write a routine that steps through every record of every table and attempts to lock it to see if I can reproduce the error that way.
>
>
Do you have Access tables inside your application or only linked
PostgreSQL tables? May be it's not abou t PostgeSQL tables at all... Try
to enable logging for ODBC driver or for the whole ODBC subsystem. It's
possible to do via Administration -> Data Sources (ODBC) -> configure
DSN or Tracing
> Thanks in advance for any suggestions anyone may offer.
>
> Fred Parkinson
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match