For those who have been following this, here's a follow-up and (hopefully)
the conclusion of this issue.

I switched the mechanism for creating a new record from going to the new
record in the bound form to creating one in the table, requerying the form,
and then going to that newly created record. The problem is gone.

So, apparently, there was some glitch with creating a new record through the
form, then immediately going to a subform and then out of it again to the
newly-created record that Access or the ODBC driver couldn't handle. As
noted, data that was entered after coming out of the subform was lost about
10% of the time, even though the users did an explicit save with the Save
Record menu command and/or Shift+Enter.

In any case, as noted, creating the new record in code and then going there
cleared up the problem. So, whatever the reason was, I'll just be doing that
from now one.

Thanks to everyone for their input!

Neil


"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:yefFd.5637$Ii4.2334@newsread3.news.pas.earthl ink.net...
> We're using SQL Server 7 with an Access 2000 MDB as a front end with ODBC
> linked tables. I recently created a new set of tables for the app, and
> users are complaining that unsaved data is being lost when they move to a
> new record. This seems to be the case when there are multiple users. When
> there is a single user using it, we don't seem to have that problem.
>
> It seems that we had this problem when we first converted from an MDB back
> end to a SQL 7 back end, years ago, but we haven't had this problem in a
> while. These are the first "entirely new" tables created in several years,
> and we seem to be having that problem again.
>
> Is this something with SQL 7 when it's dealing with new tables? Any ideas
> on what to do?
>
> Thanks!
>
> Neil
>

Neil Ginsberg wrote:
> For those who have been following this, here's a follow-up and (hopefully)
> the conclusion of this issue.
>
> I switched the mechanism for creating a new record from going to the new
> record in the bound form to creating one in the table, requerying the form,
> and then going to that newly created record. The problem is gone.
>
> So, apparently, there was some glitch with creating a new record through the
> form, then immediately going to a subform and then out of it again to the
> newly-created record that Access or the ODBC driver couldn't handle. As
> noted, data that was entered after coming out of the subform was lost about
> 10% of the time, even though the users did an explicit save with the Save
> Record menu command and/or Shift+Enter.
>
> In any case, as noted, creating the new record in code and then going there
> cleared up the problem. So, whatever the reason was, I'll just be doing that
> from now one.
>
> Thanks to everyone for their input!

That's Wierd City Arizona, glad you've got a workaround but I bet the
root cause will niggle away at the back of your mind for some time to come.

--
This sig left intentionally blank

"Trevor Best" <nospam@besty.org.uk> wrote in message
news:41f23b80$0$13392$fa0fcedb@news.zen.co.uk...
> Neil Ginsberg wrote:
>> For those who have been following this, here's a follow-up and
>> (hopefully) the conclusion of this issue.
>>
>> I switched the mechanism for creating a new record from going to the new
>> record in the bound form to creating one in the table, requerying the
>> form, and then going to that newly created record. The problem is gone.
>>
>> So, apparently, there was some glitch with creating a new record through
>> the form, then immediately going to a subform and then out of it again to
>> the newly-created record that Access or the ODBC driver couldn't handle.
>> As noted, data that was entered after coming out of the subform was lost
>> about 10% of the time, even though the users did an explicit save with
>> the Save Record menu command and/or Shift+Enter.
>>
>> In any case, as noted, creating the new record in code and then going
>> there cleared up the problem. So, whatever the reason was, I'll just be
>> doing that from now one.
>>
>> Thanks to everyone for their input!
>
> That's Wierd City Arizona,

:-)

glad you've got a workaround but I bet the
> root cause will niggle away at the back of your mind for some time to
> come.

I dunno. I've already wracked my brains so much on this, that I doubt I'll
be able to do more. I'll probably I'll just chalk it up to inadequacies in
the system and move on.

Thanks again for your input!

Neil

>
> --
> This sig left intentionally blank