Thanks, Trevor.

"Trevor Best" <nospam@besty.org.uk> wrote in message
news:41e7883a$0$6147$db0fefd9@news.zen.co.uk...
> Neil Ginsberg wrote:
>> I've tried using Profiler in the past and found it a bit unwieldy.
>> Perhaps you have some tips here. In this case, the problem is
>> intermittent, so I'd have to be able to find the command that may or may
>> not have been sent by the ODBC driver from several users over a period of
>> time. Last time I had an intermittent problem like this, I found the
>> Profiler data less than useful -- most likely due to my inexperience with
>> it, but still not very useful. Any tips?
>
> There's loads of filters you can use in Profiler. I'd recommend (in the
> first screen) getting rid of all events except TSQL:SQL:BatchCompleted, to
> simplify things, use it against your MSDE one then you needn't filter out
> other users and apps, shut down Enterprise Mangler and all other apps that
> connect to the server. (turn off timers in other forms or close them too)
>
> Start a trace just before hitting save, then end it just after, you'll get
> about half a dozen or so lines. You may recognise an update statement or
> sp_prepare /sp_Execute pair or just the first, which would indicate a
> problem (preparing to execute something but not actually doing it).
>
> Another thing, if you really can't get on with profiler is to (again just
> before the save that would fail) create an update trigger on the table
> that raises an error, go back to Access and hit save. If you get your own
> error message then this means that Access did actually try to save the
> record to the server.
>
> However if you don't there's 2 possibilities:
> 1. Access did not attempt to save the record or it failed somewhere in
> Access/ODBC b4 reaching the server or
> 2. Universal error trapping (On Error Resume Next, DoCmd.Setwarnings
> False, etc) in place.
>
>
> --
> This sig left intentionally blank

Okay then. I actually do have a pretty good understanding of
how Access works and in particular how it works when linking
tables via ODBC to various data sources and the issues that
can be encountered. I did know what you meant about the
record saving when moving around on the form. And I'm aware
of the order of events and what fires when in what order and
under what conditions. So I'm not so sure that it's
necessarily related to my not really understanding how
Access works.
I guess what you have seen fail and what I have seen fail in
Access is different but I'd rather move on for now.

-Sue

OK. Well, thanks again for your input!

Neil

"Sue Hoegemeier" <Sue_H@nomail.please> wrote in message
news:4s4gu057js7l2aa0hns6p34hai82o7a13v@4ax.com...
> Okay then. I actually do have a pretty good understanding of
> how Access works and in particular how it works when linking
> tables via ODBC to various data sources and the issues that
> can be encountered. I did know what you meant about the
> record saving when moving around on the form. And I'm aware
> of the order of events and what fires when in what order and
> under what conditions. So I'm not so sure that it's
> necessarily related to my not really understanding how
> Access works.
> I guess what you have seen fail and what I have seen fail in
> Access is different but I'd rather move on for now.
>
> -Sue

For those who have been following this, here's a note I just got from one of
the users. If this situation was bizarre before, this just brings it to a
new level.

"I type in either keynotes [varchar 255] or notes [text]. Save (using Save
Record from the Records menu). Then, if I'm working in notes and save, and
click into either keynotes or citation [varchar 255], I immediately lost all
information in both notes and keynotes. This just happened twice. And I
really do make very sure the information is saved, but it disappears anyway.
Doesn't ALWAYS happen like this, sometimes I'll click into another area and
the information doesn't get lost. But it did just happen twice that way."

So it seems the data is getting lost even before the user exits the record
(presumably, clicking in one of the other fields just brings up the latest
data in the table, which is blank in those fields).

So there's some more that goes into the pot of this weirdness.

Neil

"Neil Ginsberg" <nrg@nrgconsult.com> wrote in message
news:GLfFd.5658$Ii4.166@newsread3.news.pas.earthli nk.net...
> Another note on this issue. If I go into an existing record, type data in
> a field, save the record (using Shift+Enter), then immediately type more
> data in the same field, I get the message, "The data has been changed.
> Another user edited this record and saved the changes before you attempted
> to save your changes." Once the message is cleared, the steps of
> typing/saving/typing can be performed without any errors. But when you
> first go to a record and perform those steps, the error always comes up.
>
> This happens both on the network version of the database, as well as in my
> personal copy (using MSDE), so I know it's not a multi-user issue, but
> some kind of a glitch. It seems that it might be related to the below
> message re. losing data, so I posted it here.
>
> Any ideas?
>
> Thanks!
>
> 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 note I just got from one of
> the users. If this situation was bizarre before, this just brings it to a
> new level.
>
> "I type in either keynotes [varchar 255] or notes [text]. Save (using Save
> Record from the Records menu). Then, if I'm working in notes and save, and
> click into either keynotes or citation [varchar 255], I immediately lost all
> information in both notes and keynotes. This just happened twice. And I
> really do make very sure the information is saved, but it disappears anyway.
> Doesn't ALWAYS happen like this, sometimes I'll click into another area and
> the information doesn't get lost. But it did just happen twice that way."
>
> So it seems the data is getting lost even before the user exits the record
> (presumably, clicking in one of the other fields just brings up the latest
> data in the table, which is blank in those fields).
>
> So there's some more that goes into the pot of this weirdness.

What method do you use to save the record in code?


--
This sig left intentionally blank

As noted, I'm just using the bound form's built-in save command. In this
case, the user is selecting Save Record from Access' Records menu. Other
times, the users may move to a new record, causing Access to perform an
automatic save.

The only time where code comes into play is if the user clicks the New
button, which first performs a docmd.runcommand accmdsaverecord before
moving to the new record. But that wasn't the case here; the user just
selected the built-in Save Record command.

Neil

"Trevor Best" <nospam@besty.org.uk> wrote in message
news:41e8f80f$0$4358$fa0fcedb@news.zen.co.uk...
> Neil Ginsberg wrote:
>> For those who have been following this, here's a note I just got from one
>> of the users. If this situation was bizarre before, this just brings it
>> to a new level.
>>
>> "I type in either keynotes [varchar 255] or notes [text]. Save (using
>> Save Record from the Records menu). Then, if I'm working in notes and
>> save, and click into either keynotes or citation [varchar 255], I
>> immediately lost all information in both notes and keynotes. This just
>> happened twice. And I really do make very sure the information is saved,
>> but it disappears anyway. Doesn't ALWAYS happen like this, sometimes I'll
>> click into another area and the information doesn't get lost. But it did
>> just happen twice that way."
>>
>> So it seems the data is getting lost even before the user exits the
>> record (presumably, clicking in one of the other fields just brings up
>> the latest data in the table, which is blank in those fields).
>>
>> So there's some more that goes into the pot of this weirdness.
>
> What method do you use to save the record in code?
>
>
> --
> This sig left intentionally blank

Neil Ginsberg wrote:
> As noted, I'm just using the bound form's built-in save command. In this
> case, the user is selecting Save Record from Access' Records menu. Other
> times, the users may move to a new record, causing Access to perform an
> automatic save.
>
> The only time where code comes into play is if the user clicks the New
> button, which first performs a docmd.runcommand accmdsaverecord before
> moving to the new record. But that wasn't the case here; the user just
> selected the built-in Save Record command.

And everything's patched? e.g. Latest Service Pack for Access (SP3) and
MDAC2.8 (will be if WinXP as it's part of the OS now).

--
This sig left intentionally blank

Yes.

By the way, I tried the trace, but the users complained that it was slowing
things down, and I had to turn it off.

Which newsgroup do you read this in?

Thanks,

Neil

"Trevor Best" <nospam@besty.org.uk> wrote in message
news:41ea5889$0$4374$fa0fcedb@news.zen.co.uk...
> Neil Ginsberg wrote:
>> As noted, I'm just using the bound form's built-in save command. In this
>> case, the user is selecting Save Record from Access' Records menu. Other
>> times, the users may move to a new record, causing Access to perform an
>> automatic save.
>>
>> The only time where code comes into play is if the user clicks the New
>> button, which first performs a docmd.runcommand accmdsaverecord before
>> moving to the new record. But that wasn't the case here; the user just
>> selected the built-in Save Record command.
>
> And everything's patched? e.g. Latest Service Pack for Access (SP3) and
> MDAC2.8 (will be if WinXP as it's part of the OS now).
>
> --
> This sig left intentionally blank

Neil Ginsberg wrote:
> Yes.
>
> By the way, I tried the trace, but the users complained that it was slowing
> things down, and I had to turn it off.

That's another reason to try it on your MSDE :-)

> Which newsgroup do you read this in?

comp.databases.ms-access


--
This sig left intentionally blank

"Trevor Best" <nospam@besty.org.uk> wrote in message
news:41ecc6bf$0$15395$db0fefd9@news.zen.co.uk...
> Neil Ginsberg wrote:
>> Yes.
>>
>> By the way, I tried the trace, but the users complained that it was
>> slowing things down, and I had to turn it off.
>
> That's another reason to try it on your MSDE :-)

Yeah, well, I can't even get the problem to occur on my MSDE! I even tried
an automated data entry thing using SendKeys and creating 500 records.
Didn't lose data once. So I don't know what the f* is going on over there,
but users are experiencing it consistently enough that I don't think it's a
fluke user-error thing.

Neil

>
>> Which newsgroup do you read this in?
>
> comp.databases.ms-access
>
>
> --
> This sig left intentionally blank