not a valid bookmark - not using a recordset

[ml_sauls]

I've built a system to enter and manage purchase orders. This is in
use by >10 clients. Some use it in Access 97, most are in A2k. About
half use it through a Citrix implementation. It is separated into a
front end and 3 back ends (1 network for permanent storage, 1 local for
temp storage, and 1 local for storage for particular user).

One particular form is failing for a single client (Access 2000, using
Citrix). This form is a form with a subform, used for entering po's.
The outer form contains summary information, such as vendor. The child
form is for entering lines. In order, the fields are account,
quantity, unit price, extended (qty * unit), then two free text fields.
It is bound to the outer form on a shared id, which uses an autonumber
key to assure a unique id across all users.

This single client encounters an error when moving from the unit price
field to the first free text field. All fields on the current line
display #error. The error message displayed is "Not a valid bookmark".
The only code on the unit price field is to set the extended cost
value equal to quantity * unit price. The error message is not
produced through my error trap. If I ctrl+break to see what executes
next, nothing does

Neither the parent nor child form uses a recordset. I have not
declared, nor do I use, any bookmarks on either form. I've declared
recordsets on each, which are used solely within their subs or
functions, then killed when exiting the sub or function. The parent
form is unbound, the child form is bound. The error is not consistent.
Sometimes it fails on the 2nd po to be entered, sometimes the 4th,
sometimes further out. I have not yet seen it fail on the 1st. If the
form is closed then reopened, the first entered will not encounter
errors. Once it has produced the error, even rolling the mouse over
the subform will produce it. The error message box will sometimes be
displayed multiple times.

I cannot find any consistency in the number of times the error is
displayed, or in the number of entries it will accept prior to
producing it, though it is typically between 2 and 12.
I cannot find any consistency in the data used in the record that
produces the error.
I have reconfigured the client's application from the master.
I have relinked another client's application to this client's tables
and encounter the error.
I have relinked this client's app to another client's tables and do not
encounter the error.
I can use another client's accounts with the client's app & tables and
do not encounter the error.
I can use this client's accounts with another client's app & tables and
do encounter the error.
I do not see any differences between Citrix vs non-citrix, though
another tester reports that the error is not encountered in a
non-Citrix environment.
I've not yet encountered the error if I enter all detail lines in the
subform first, then enter data in the outer form.
I've tried placing break points and error handlers within all code on
the subform, as well as the subform object on the parent form. None of
these are encountered when this error is produced.

I have rebuilt all tables. I noticed when testing, that sorting
certain fields in the account table would produce this error, when
viewing them through the table link. These were text fields, using the
A-Z button to sort asc/desc. I rebuilt that table from scratch. I
repopulated it by exporting data from the former table to a text file,
then importing the data from that text file. This did not change the
testing results.

My only thought for a fix is to entirely redesign the form to eliminate
use of a subform, which will take more time than I currently have
available. Of course, on the other hand, I'd be partly done with it if
I'd not done so much testing/rebuilding.

I am at a loss as to what could be causing this error? Any ideas?

[ml_sauls]

Apologies - both the parent and child forms are bound to tables, each a
different table. Both are in the local back end.

[deluxeinformation]

ml_sauls wrote:

Apologies - both the parent and child forms are bound to tables, each a
different table. Both are in the local back end.

Doesn't using Citrix mean that you have multiple users using the same
copy of the front end? Does this also mean that you have multiple
users using the same copy of the 'local' and 'temporary storage'
databases? Have you determined whether the problem happens when
multiple users are accessing these databases via Citrix? You might
want to revisit the storage architecture of your back end databases.

Have you compacted and repaired all databases? Does this particular
Access 2000 installation have the latest service packs installed?

Bruce

[David W. Fenton]

de************* **@gmail.com wrote in
news:11******** **************@ e3g2000cwe.goog legroups.com:

Doesn't using Citrix mean that you have multiple users using the
same copy of the front end?

Only if you've set it up wrong.

Under a terminal server setup, you'd do exactly the same as running
on individual workstations -- each user gets an individual copy of
the front end. Failing to do that leads to the same problems that
any sharing of a front end causes.

Someone people seem allergic to doing this with some idea that it's
wasteful of disk space. Well, unless you have a 1GB front end (which
would mean you're doing something incredibly wrong), I can't see how
it would be an issue. The front ends of most of my clients'
applications are under 10MBs, so even supporting 100 users isn't a
significant amount of disk space on modern-day servers.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[ml_sauls]

Though it is through Citrix, neither the front end or either of the
local table files are shared by multiple users. Even if it were, all
my testing was with only me, which tells me that even if sharing causes
other issues, it does not seem to be a factor in this instance.

Yes, I have rebuilt all databases, including compact/repair. The front
end has been reconfigured from an unused master. I have also
decompiled/recompiled that. I have been assured that the client is
running A2k with all service packs installed. Regardless, I know the
local environment at work has all service packs installed, and again,
that's where I'm testing and where I'm getting an error. OS is Windows
xp.

I've cut my losses on testing and have begun redesigning both the
parent and subform to be unbound. Though I've been unable to pinpoint
just *why* this error occurs, I am hoping that making everything
unbound will eliminate it.

de************* **@gmail.com wrote:

Doesn't using Citrix mean that you have multiple users using the same
copy of the front end? Does this also mean that you have multiple
users using the same copy of the 'local' and 'temporary storage'
databases? Have you determined whether the problem happens when
multiple users are accessing these databases via Citrix? You might
want to revisit the storage architecture of your back end databases.

Have you compacted and repaired all databases? Does this particular
Access 2000 installation have the latest service packs installed?

Bruce

[scottkirk]

ml_sauls wrote:

Though it is through Citrix, neither the front end or either of the
local table files are shared by multiple users. Even if it were, all
my testing was with only me, which tells me that even if sharing causes
other issues, it does not seem to be a factor in this instance.

Yes, I have rebuilt all databases, including compact/repair. The front
end has been reconfigured from an unused master. I have also
decompiled/recompiled that. I have been assured that the client is
running A2k with all service packs installed. Regardless, I know the
local environment at work has all service packs installed, and again,
that's where I'm testing and where I'm getting an error. OS is Windows
xp.

I've cut my losses on testing and have begun redesigning both the
parent and subform to be unbound. Though I've been unable to pinpoint
just *why* this error occurs, I am hoping that making everything
unbound will eliminate it.

de************* **@gmail.com wrote:

Doesn't using Citrix mean that you have multiple users using the same
copy of the front end? Does this also mean that you have multiple
users using the same copy of the 'local' and 'temporary storage'
databases? Have you determined whether the problem happens when
multiple users are accessing these databases via Citrix? You might
want to revisit the storage architecture of your back end databases.

Have you compacted and repaired all databases? Does this particular
Access 2000 installation have the latest service packs installed?

Bruce

Please pass along if this resolves the issue. I have had similar
problem pop up in the last 3 months. My issue is not on a citrix box
but does occur only on some workstations and randomly during data
entry. This is ony happening on Access XP or 03 with an access back
end. If I use Sql Server I have nothing like this.

I too am pulling my hair out over this issue.

Thanks

Scott

[David W. Fenton]

"ml_sauls" <ml******@yahoo .comwrote in
news:11******** *************@h 48g2000cwc.goog legroups.com:

I have rebuilt all databases, including compact/repair. The front
end has been reconfigured from an unused master. I have also
decompiled/recompiled that. I have been assured that the client
is running A2k with all service packs installed. Regardless, I
know the local environment at work has all service packs
installed, and again, that's where I'm testing and where I'm
getting an error. OS is Windows xp.

This is a corruption issue, without doubt, as Peter Miller, who is
the recognized non-Microsoft expert on Jet, says in this post (all
on one line, of course):

http://groups.google.com/group/comp..../msg/6a68a5c1d
4c34872

I've cut my losses on testing and have begun redesigning both the
parent and subform to be unbound. Though I've been unable to
pinpoint just *why* this error occurs, I am hoping that making
everything unbound will eliminate it.

Unbound may avoid the error, but it won't eliminate the problem
that's causing the corruption. You need to fix *that*.

Keep in mind that the corruption could be in particular records, so
you may need to import groups of records into your new database,
rather than just importing the table structures and data all at
once. Peter advises importing the data structure, then importing
groups of records until you find the corrupted records.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[scottkirk]

David W. Fenton wrote:

"ml_sauls" <ml******@yahoo .comwrote in
news:11******** *************@h 48g2000cwc.goog legroups.com:

I have rebuilt all databases, including compact/repair. The front
end has been reconfigured from an unused master. I have also
decompiled/recompiled that. I have been assured that the client
is running A2k with all service packs installed. Regardless, I
know the local environment at work has all service packs
installed, and again, that's where I'm testing and where I'm
getting an error. OS is Windows xp.

This is a corruption issue, without doubt, as Peter Miller, who is
the recognized non-Microsoft expert on Jet, says in this post (all
on one line, of course):

http://groups.google.com/group/comp..../msg/6a68a5c1d
4c34872

I've cut my losses on testing and have begun redesigning both the
parent and subform to be unbound. Though I've been unable to
pinpoint just *why* this error occurs, I am hoping that making
everything unbound will eliminate it.

Unbound may avoid the error, but it won't eliminate the problem
that's causing the corruption. You need to fix *that*.

Keep in mind that the corruption could be in particular records, so
you may need to import groups of records into your new database,
rather than just importing the table structures and data all at
once. Peter advises importing the data structure, then importing
groups of records until you find the corrupted records.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

I have created new databases and imported the data in with no errors or
problems. The error happens during data entry. I always thought
corruption until I did everything by the book and it still happens.

Thanks!

Scott

[David W. Fenton]

sc*******@gmail .com wrote in
news:11******** **************@ h48g2000cwc.goo glegroups.com:

>
David W. Fenton wrote:

>"ml_sauls" <ml******@yahoo .comwrote in
news:11******* **************@ h48g2000cwc.goo glegroups.com:

I have rebuilt all databases, including compact/repair. The
front end has been reconfigured from an unused master. I have
also decompiled/recompiled that. I have been assured that the
client is running A2k with all service packs installed.
Regardless, I know the local environment at work has all
service packs installed, and again, that's where I'm testing
and where I'm getting an error. OS is Windows xp.

This is a corruption issue, without doubt, as Peter Miller, who
is the recognized non-Microsoft expert on Jet, says in this post
(all on one line, of course):

http://groups.google.com/group/comp....ess/msg/6a68a5
c1d 4c34872

I've cut my losses on testing and have begun redesigning both
the parent and subform to be unbound. Though I've been unable
to pinpoint just *why* this error occurs, I am hoping that
making everything unbound will eliminate it.

Unbound may avoid the error, but it won't eliminate the problem
that's causing the corruption. You need to fix *that*.

Keep in mind that the corruption could be in particular records,
so you may need to import groups of records into your new
database, rather than just importing the table structures and
data all at once. Peter advises importing the data structure,
then importing groups of records until you find the corrupted
records.

I have created new databases and imported the data in with no
errors or problems. The error happens during data entry. I
always thought corruption until I did everything by the book and
it still happens.

It *is* corruption.

And simply importing the tables into a new database is likely
carrying over the corruption from the old data, as it is data-based
corruption (i.e., corruption in particular rows), not structural at
the table level or higher.

You need to follow the instructions in the post cited above, and
*not* just do a single import of table and data together, but import
structure first and then finite sets of data until the error occurs,
at which point you'll have found the corrupted record(s) which you
can replace with a new one and then delete the corrupt one.

It could also be that the new database you create is fine and as
soon as someone edits it, whatever is causing the corruption in the
first place kicks in and corrupts it again. You need to solve the
real problem, which is not that your database is corrupt, but that
something is repeatedly causing your database to become corrupted.
Remove the cause and you don't need fix corrupt databases any more.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[scottkirk]

On Oct 24, 3:43 pm, "David W. Fenton" <XXXuse...@dfen ton.com.invalid >
wrote:

scottk...@gmail .com wrote innews:11****** *************** *@h48g2000cwc.g ooglegroups.com :

David W. Fenton wrote:

"ml_sauls" <ml_sa...@yahoo .comwrote in
news:11******* **************@ h48g2000cwc.goo glegroups.com:

I have rebuilt all databases, including compact/repair. The
front end has been reconfigured from an unused master. I have
also decompiled/recompiled that. I have been assured that the
client is running A2k with all service packs installed.
Regardless, I know the local environment at work has all
service packs installed, and again, that's where I'm testing
and where I'm getting an error. OS is Windows xp.

This is a corruption issue, without doubt, as Peter Miller, who
is the recognized non-Microsoft expert on Jet, says in this post
(all on one line, of course):

>http://groups.google.com/group/comp....ess/msg/6a68a5
c1d 4c34872

I've cut my losses on testing and have begun redesigning both
the parent and subform to be unbound. Though I've been unable
to pinpoint just *why* this error occurs, I am hoping that
making everything unbound will eliminate it.

Unbound may avoid the error, but it won't eliminate the problem
that's causing the corruption. You need to fix *that*.

Keep in mind that the corruption could be in particular records,
so you may need to import groups of records into your new
database, rather than just importing the table structures and
data all at once. Peter advises importing the data structure,
then importing groups of records until you find the corrupted
records.

I have created new databases and imported the data in with no
errors or problems. The error happens during data entry. I
always thought corruption until I did everything by the book and
it still happens.It *is* corruption.

And simply importing the tables into a new database is likely
carrying over the corruption from the old data, as it is data-based
corruption (i.e., corruption in particular rows),notstruct ural at
the table level or higher.

You need to follow the instructions in the post cited above, and
*not* just do a single import of table and data together, but import
structure first and then finite sets of data until the error occurs,
at which point you'll have found the corrupted record(s) which you
can replace with a new one and then delete the corrupt one.

It could also be that the new database you create is fine and as
soon as someone edits it, whatever is causing the corruption in the
first place kicks in and corrupts it again. You need to solve the
real problem, which isnotthat your database is corrupt, but that
something is repeatedly causing your database to become corrupted.
Remove the cause and you don't need fix corrupt databases any more.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/- Hide quoted text -- Show quoted text -

Do you think its possible that the program or data in the program could
cause this?

Thanks

Scott