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.googlegro ups.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*********************@h48g2000cwc.googlegro ups.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*********************@h48g2000cwc.googlegro ups.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.googlegr oups.com:

>
David W. Fenton wrote:

>"ml_sauls" <ml******@yahoo.comwrote in
news:11*********************@h48g2000cwc.googlegr oups.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" <[e-mail]>
wrote:

[e-mail] wrote innews:11**********************@h48g2000cwc.google groups.com:

David W. Fenton wrote:

"ml_sauls" <[e-mail] in
news:11*********************@h48g2000cwc.googlegr oups.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),notstructural 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

[David W. Fenton]

sc*******@gmail.com wrote in
news:11**********************@k70g2000cwa.googlegr oups.com:

On Oct 24, 3:43 pm, "David W. Fenton"
<[e-mail] wrote:

>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.

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

Corruption? No.

Something could be interfering with the file writes, but it won't be
internal to the application or to the data. It could be dropped or
unreliable network connections. It could be virus scanners. It could
be any software running on the server.

The only situation where the software makes a difference is when
you're using one of the buggy versions of Access or Jet, but you
said you were up-to-date on all of those, no? The key one is that
you need Jet SP6 or later. The most common versions I run into are 8
and 9.

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

[scottkirk]

On Oct 25, 12:58 pm, "David W. Fenton" <[e-mail]>
wrote:

[e-mail] wrote innews:11**********************@k70g2000cwa.google groups.com:

On Oct 24, 3:43 pm, "David W. Fenton"
<[e-mail] wrote:

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.

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

Something could be interfering with the file writes, but it won't be
internal to the application or to the data. It could be dropped or
unreliable network connections. It could be virus scanners. It could
be any software running on the server.

The only situation where the software makes a difference is when
you're using one of the buggy versions of Access or Jet, but you
said you were up-to-date on all of those, no? The key one is that
you need Jet SP6 or later. The most common versions I run into are 8
and 9.

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

All are running latest SP2 and Jet 8. I'll review the data again but
would appreciate any other ideas.

Scott

[David W. Fenton]

sc*******@gmail.com wrote in
news:11*********************@i3g2000cwc.googlegrou ps.com:

All are running latest SP2 and Jet 8. I'll review the data again
but would appreciate any other ideas.

Have you really gone to each PC and checked this? I one time had a
case where I was just sure I'd patched all the machines, and then I
implemented code in the app to log Access and Jet versions, and
discovered ONE MACHINE with the original Access and no Jet service
packs. Once it was patched, the corruption stopped for good.

Logging that at startup is a good thing, because it's really easy
for machines to revert when somebody wipes the drive and rebuilds
it, or installs something that overwrites later versions.

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

[scottkirk]

On Oct 25, 4:26 pm, "David W. Fenton" <[e-mail]>
wrote:

[e-mail] wrote innews:11*********************@i3g2000cwc.googlegr oups.com:

All are running latest SP2 and Jet 8. I'll review the data again
but would appreciate any other ideas. Have you really gone to each PC and checked this? I one time had a

case where I was just sure I'd patched all the machines, and then I
implemented code in the app to log Access and Jet versions, and
discovered ONE MACHINE with the original Access and no Jet service
packs. Once it was patched, the corruption stopped for good.

Logging that at startup is a good thing, because it's really easy
for machines to revert when somebody wipes the drive and rebuilds
it, or installs something that overwrites later versions.

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

I know what you mean. Any recommendations on code to capture the jet
version at login?

Thanks!

Scott

[David W. Fenton]

sc*******@gmail.com wrote in
news:11**********************@m7g2000cwm.googlegro ups.com:

On Oct 25, 4:26 pm, "David W. Fenton"
<[e-mail]:

>[e-mail] wrote
innews:11*********************@i3g2000cwc.googleg roups.com:

All are running latest SP2 and Jet 8. I'll review the data
again but would appreciate any other ideas. Have you really
gone to each PC and checked this? I one time had a

case where I was just sure I'd patched all the machines, and then
I implemented code in the app to log Access and Jet versions, and
discovered ONE MACHINE with the original Access and no Jet
service packs. Once it was patched, the corruption stopped for
good.

Logging that at startup is a good thing, because it's really easy
for machines to revert when somebody wipes the drive and rebuilds
it, or installs something that overwrites later versions.

I know what you mean. Any recommendations on code to capture the
jet version at login?

I got the code either from http://mvps.org/access or from Tony Toews
website. I can't remember which.

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