Subject | Re: [IBO] Cursor unknown error -504 |
---|---|
Author | Helen Borrie |
Post date | 2004-08-09T01:58:10Z |
At 12:23 AM 9/08/2004 +0000, Bob Zirbel wrote:
you are refreshing something by timer, then you are closing and opening
datasets. If you are using an Autocommit transaction, you are retaining
cursors.
This error is about a database cursor - it's the client asking the server
to work from a set pointer in a cursor that either has gone or never was
there.
Alan's thoughts about DB_KEY would be a useful direction to look, if your
table doesn't have a primary key and/or the application doesn't know what
the primary key is, for whatever reason. Keylinks that are present but
wrong would cause different exceptions, which you haven't reported.
Under the hood, the application is asking to do something to a row WHERE
CURRENT OF a certain unique key. If the only unique key in your set, known
to the client and the server, is the DB_KEY, then the cursor pointer will
only be valid if the same record can be found by locating the db_key that
the application thinks it has. Remember, the db_key refers to a spatial
relative location, it's not a data key. It won't be found at that location
if someone (including your user) updated the record and the new record
version has been written to a different relative location; or if someone
deleted the record.
For me, this thread has become quite muddled, with a confused mix of
problem descriptions and conditions, so I'll be happy to leave it to you
and others to resolve.
Helen
> > Not sure this stacks up Helen, I can leave the app sitting thereFirst, if there is data in the grid, then there is an open transaction. If
>for an hour
> > and it timer refreshes every 5 minutes. Noone touches it, no
>errors until
> > say the 13th or 20th save, then on this 13th or maybe 20th save,
>the cursur
> > unknown error pops up. That's on my dev platform with one user
>sitting on
> > it.
> >
> > Alan
>
>I agree with Alan, Helen, my app is only displaying data in the
>grid. As far as I know, unless there is a bug, there are no open
>transactions.
you are refreshing something by timer, then you are closing and opening
datasets. If you are using an Autocommit transaction, you are retaining
cursors.
This error is about a database cursor - it's the client asking the server
to work from a set pointer in a cursor that either has gone or never was
there.
Alan's thoughts about DB_KEY would be a useful direction to look, if your
table doesn't have a primary key and/or the application doesn't know what
the primary key is, for whatever reason. Keylinks that are present but
wrong would cause different exceptions, which you haven't reported.
Under the hood, the application is asking to do something to a row WHERE
CURRENT OF a certain unique key. If the only unique key in your set, known
to the client and the server, is the DB_KEY, then the cursor pointer will
only be valid if the same record can be found by locating the db_key that
the application thinks it has. Remember, the db_key refers to a spatial
relative location, it's not a data key. It won't be found at that location
if someone (including your user) updated the record and the new record
version has been written to a different relative location; or if someone
deleted the record.
For me, this thread has become quite muddled, with a confused mix of
problem descriptions and conditions, so I'll be happy to leave it to you
and others to resolve.
Helen