o2k - more thoughts on moving to multi-user - comments?

I've posted about this subject before but haven't really got anywhere yet.
I have now come up with a plan of action that takes into account my strong
desire to implement save/discard functionality on all key forms.

The first thing to do is to successfully split the database.
I then rewrite to support multiple users.

To allow the save/discard feature I create copies of the key tables and
append the word Final to each one.
For example I create a copy of tblEmployees and call it tblEmployeesFinal.

Then once a user clicks the Save button on frmEmployees (bound to
tblEmployees) or are prompted to Save, their changes are copied to
tblEmployeesFinal.
tblEmployeesFinal now represents the prime record, though tblEmployees will
also be identical.

If the user discards their changes then we want the changes to tblEmployees
to be rolled back. I do this by overwriting the specific records in
tblEmployees with those from tblEmployeesFinal.

The work to update the tables is performed by an Action query. I'm thinking
of wrapping these up in a transaction so that they always complete or always
fail. That way the tables can be guaranteed to be identical.

Any comments on this?

thanks
Martin
--

re: o2k - more thoughts on moving to multi-user - comments?

er, i meant Access 2000 (i.e a2k)



--

re: o2k - more thoughts on moving to multi-user - comments?

What you're trying to do is a very good thing, but it's not trivial.

First - it is almost never a good idea to create 2 tables to hold data that
has the same structure, and to do that across a whole set of tables is a
nightmare. I would not do that. The problem is that you have to keep those
table designs in sync as structural changes are made later. You'll find that
a lot of queries, forms, etc. must also be duplicated or made more complex.

Instead, what you usually want to do is add a status field to each table, and
change the status. In your case, the values for status might represent
"Draft", "Current", and "History".

The first challenge, then will be how to keep relationships to records in sync
as those records change status. One way you can do that is to have a primary
key for the physical record and add another logical entity key that is
preserved across the various revisions. The logical entity key is created
once for the first record by copying the primary key, then it is copied to
subsequent revisions.

The next challenge will be how to make sure there can never be 2 records with
the same logical entity key that are both current. Even if your code tries to
maintain that, if someone crashes at just the wrong time, there could be a
problem - or you could end up with -no- current instance. You could just code
carefully and live with the risk (not too bad a choice actually) perhaps use a
trick to get database integrity to help maintian logical integrity. I'm
thinking you could use a copy of the physical key in the status field to
represent "historical" status, but leave the status codes for "current" and
"draft" unique. Then, you can use a unique index on the combination of
logical key and status to enforce that there can only be one "current" and one
"draft" while still allowing multiple "historical" records.

For example:

Before edit:
PK LK Status First Name
1 1 "C" "Jhon"

New draft in progress:
PK LK Status First Name
1 1 "C" "Jhon"
2 1 "D" "John"

After draft saved as current:
PK LK Status First Name
1 1 "1" "Jhon"
2 1 "C" "John"

You'll also want to decide how to handle detail records. In some cases where
the detail records are logical child components of a master record, you'll
want to edit them as a single logical entity via a master/sub form. I admit,
I haven't figured out a nice way to deal with that yet.

You can copy all the details and use the master record for status, but then
you'll have to relate to them using the combination of logical master and
detail key, using the master record as part of each query - yuck. You can
copy all the details, give them all "draft" status, and update them in the
same transaction as the parent, but that's complex to maintain and creates new
copies of details that do not change. Finally, you can deal with each detail
as its own entity, creating drafts every time you make a change, just for the
changed records, but that probably means using a dialog form for editing
details rather than editing them in-place in the subform. The update would
still be more complex to take details into account, but copies of unchanged
details would not be made.

On Thu, 7 Jul 2005 14:51:03 +0100, "Deano" <deano@mailinator.com> wrote:
[color=blue]
>I've posted about this subject before but haven't really got anywhere yet.
>I have now come up with a plan of action that takes into account my strong
>desire to implement save/discard functionality on all key forms.
>
>The first thing to do is to successfully split the database.
>I then rewrite to support multiple users.
>
>To allow the save/discard feature I create copies of the key tables and
>append the word Final to each one.
>For example I create a copy of tblEmployees and call it tblEmployeesFinal.
>
>Then once a user clicks the Save button on frmEmployees (bound to
>tblEmployees) or are prompted to Save, their changes are copied to
>tblEmployeesFinal.
>tblEmployeesFinal now represents the prime record, though tblEmployees will
>also be identical.
>
>If the user discards their changes then we want the changes to tblEmployees
>to be rolled back. I do this by overwriting the specific records in
>tblEmployees with those from tblEmployeesFinal.
>
>The work to update the tables is performed by an Action query. I'm thinking
>of wrapping these up in a transaction so that they always complete or always
>fail. That way the tables can be guaranteed to be identical.
>
>Any comments on this?
>
>thanks
>Martin[/color]

re: o2k - more thoughts on moving to multi-user - comments?

Steve Jorgensen wrote:[color=blue]
> What you're trying to do is a very good thing, but it's not trivial.
>
> First - it is almost never a good idea to create 2 tables to hold
> data that has the same structure, and to do that across a whole set
> of tables is a nightmare. I would not do that. The problem is that
> you have to keep those table designs in sync as structural changes
> are made later. You'll find that a lot of queries, forms, etc. must
> also be duplicated or made more complex.
>
> Instead, what you usually want to do is add a status field to each
> table, and change the status. In your case, the values for status
> might represent "Draft", "Current", and "History".
>
> The first challenge, then will be how to keep relationships to
> records in sync as those records change status. One way you can do
> that is to have a primary key for the physical record and add another
> logical entity key that is preserved across the various revisions.
> The logical entity key is created once for the first record by
> copying the primary key, then it is copied to subsequent revisions.
>
> The next challenge will be how to make sure there can never be 2
> records with the same logical entity key that are both current. Even
> if your code tries to maintain that, if someone crashes at just the
> wrong time, there could be a problem - or you could end up with -no-
> current instance. You could just code carefully and live with the
> risk (not too bad a choice actually) perhaps use a trick to get
> database integrity to help maintian logical integrity. I'm thinking
> you could use a copy of the physical key in the status field to
> represent "historical" status, but leave the status codes for
> "current" and "draft" unique. Then, you can use a unique index on
> the combination of logical key and status to enforce that there can
> only be one "current" and one "draft" while still allowing multiple
> "historical" records.
>
> For example:
>
> Before edit:
> PK LK Status First Name
> 1 1 "C" "Jhon"
>
> New draft in progress:
> PK LK Status First Name
> 1 1 "C" "Jhon"
> 2 1 "D" "John"
>
> After draft saved as current:
> PK LK Status First Name
> 1 1 "1" "Jhon"
> 2 1 "C" "John"
>
> You'll also want to decide how to handle detail records. In some
> cases where the detail records are logical child components of a
> master record, you'll want to edit them as a single logical entity
> via a master/sub form. I admit, I haven't figured out a nice way to
> deal with that yet.
>
> You can copy all the details and use the master record for status,
> but then you'll have to relate to them using the combination of
> logical master and detail key, using the master record as part of
> each query - yuck. You can copy all the details, give them all
> "draft" status, and update them in the same transaction as the
> parent, but that's complex to maintain and creates new copies of
> details that do not change. Finally, you can deal with each detail
> as its own entity, creating drafts every time you make a change, just
> for the changed records, but that probably means using a dialog form
> for editing details rather than editing them in-place in the subform.
> The update would still be more complex to take details into account,
> but copies of unchanged details would not be made.[/color]

Thanks, that was an interesting read. The problem for me is that subforms
are of critical importance. One saving grace is that I don't create that
many records.
For each parent record there is always the same number of child/detail
records - always. They contain row upon row of checkboxes which can be
selected.

I know my original suggestion is a bit iffy but I might give it a try on a
smaller db and see what the problems are. This is really the sort of thing
that I wish Access had built in as an internal feature.


--

Deano
Gamertag: buckskin

re: o2k - more thoughts on moving to multi-user - comments?

Deano wrote:[color=blue]
> I've posted about this subject before but haven't really got anywhere
> yet. I have now come up with a plan of action that takes into account
> my strong desire to implement save/discard functionality on all key
> forms.[/color]

As a quick update, for anyone who's interested, I'm now reworking my forms
so that they are read-only in the first instance.
With continuous forms, each record has an edit button that will display an
unbound form containing the contents of the record. This was I can get
save/discard functionality without tearing apart the app or going with my
first instincts of doubling up on tables - a bad idea really as Steve
rightly pointed out.

I've only mocked up the forms but it looks alot more professional already
and will avoid accidental changes to current data and I think I will learn
alot in following this through.



--

re: o2k - more thoughts on moving to multi-user - comments?

On Mon, 11 Jul 2005 20:24:21 +0100, "Deano" <deano@mailinator.com> wrote:
[color=blue]
>Deano wrote:[color=green]
>> I've posted about this subject before but haven't really got anywhere
>> yet. I have now come up with a plan of action that takes into account
>> my strong desire to implement save/discard functionality on all key
>> forms.[/color]
>
>As a quick update, for anyone who's interested, I'm now reworking my forms
>so that they are read-only in the first instance.
>With continuous forms, each record has an edit button that will display an
>unbound form containing the contents of the record. This was I can get
>save/discard functionality without tearing apart the app or going with my
>first instincts of doubling up on tables - a bad idea really as Steve
>rightly pointed out.
>
>I've only mocked up the forms but it looks alot more professional already
>and will avoid accidental changes to current data and I think I will learn
>alot in following this through.[/color]

A couple of things to keep in mind with this approach.

1. Although you are reducing the chances of accidental update, you are also
making the application a bit more more modal and requiring more clicks to do
things which makes the app more awkward to use. It still may be the best
answer for the priorities you're trying to manage, but keep it in mind, and
try to make the UI flow as smoothly as possible.

2. Access sometimes has synchronization issues regarding multiple interactions
with the same data. Frequently, changes made using DAO or ADO in code behind
an unbound form will not be displayed in a bound form when it is subsequently
refreshed or updated without first first adding some indeterminate delay.
None of the standard recommendations for making the problem go away seem to
have any effect at all. In particular, DBEngine.Idle never seems to have any
effect.

re: o2k - more thoughts on moving to multi-user - comments?

Steve Jorgensen wrote:[color=blue]
> On Mon, 11 Jul 2005 20:24:21 +0100, "Deano" <deano@mailinator.com>
> wrote:
>[color=green]
>> Deano wrote:[color=darkred]
>>> I've posted about this subject before but haven't really got
>>> anywhere yet. I have now come up with a plan of action that takes
>>> into account my strong desire to implement save/discard
>>> functionality on all key forms.[/color]
>>
>> As a quick update, for anyone who's interested, I'm now reworking my
>> forms so that they are read-only in the first instance.
>> With continuous forms, each record has an edit button that will
>> display an unbound form containing the contents of the record. This
>> was I can get save/discard functionality without tearing apart the
>> app or going with my first instincts of doubling up on tables - a
>> bad idea really as Steve rightly pointed out.
>>
>> I've only mocked up the forms but it looks alot more professional
>> already and will avoid accidental changes to current data and I
>> think I will learn alot in following this through.[/color]
>
> A couple of things to keep in mind with this approach.
>
> 1. Although you are reducing the chances of accidental update, you
> are also making the application a bit more more modal and requiring
> more clicks to do things which makes the app more awkward to use. It
> still may be the best answer for the priorities you're trying to
> manage, but keep it in mind, and try to make the UI flow as smoothly
> as possible.[/color]

Yes, good point, though I'm hoping it will be seen as an improvement and
more in keeping with the other apps my clients use. I have to make an
interesting call with one tab; it is neither a subform nor a continuous
form. Logically I should also add another edit form for this but it would
show exactly the same number of fields, though it would look slightly
different.
I'm tempted to unbind that form and add edit/discard changes button on the
main form.

My other forms are alot more complicated and I think removing the
complicated subform would simply the look.

I was in a meeting yesterday with a software vendor and i noted how big the
fonts were on some icons. They said the smaller the font the more "complex"
the app appears to end users. And my complex forms have to be small to fit
on the screen - so making this change might improve the perception of the
app.

After all it's only when they want to change something that they should
really need to use the subform. It's alot of work but I feel it's a good
approach.
[color=blue]
>
> 2. Access sometimes has synchronization issues regarding multiple
> interactions with the same data. Frequently, changes made using DAO
> or ADO in code behind an unbound form will not be displayed in a
> bound form when it is subsequently refreshed or updated without first
> first adding some indeterminate delay. None of the standard
> recommendations for making the problem go away seem to have any
> effect at all. In particular, DBEngine.Idle never seems to have any
> effect.[/color]

And now you scare me again Steve :)

--

re: o2k - more thoughts on moving to multi-user - comments?

On Tue, 12 Jul 2005 11:25:37 +0100, "Deano" <deano@mailinator.com> wrote:
[color=blue]
>Steve Jorgensen wrote:[color=green]
>> On Mon, 11 Jul 2005 20:24:21 +0100, "Deano" <deano@mailinator.com>
>> wrote:
>>[/color][/color]
....[color=blue][color=green]
>> 2. Access sometimes has synchronization issues regarding multiple
>> interactions with the same data. Frequently, changes made using DAO
>> or ADO in code behind an unbound form will not be displayed in a
>> bound form when it is subsequently refreshed or updated without first
>> first adding some indeterminate delay. None of the standard
>> recommendations for making the problem go away seem to have any
>> effect at all. In particular, DBEngine.Idle never seems to have any
>> effect.[/color]
>
>And now you scare me again Steve :)[/color]

I think there's a thread somewhere on this newsgroup with an answer that
actually might work, but I can never seem to find it. It's some registry
setting for the JET engine.

My usual work-around is to update the form's recordset directly since even if
the form has Alow Edits: No, the code can update the form's recordset. With
what you're doing, though, I don't think that will work the way I've been
doing it because you're not simply editing records in place, you're changing
data that determines which records should be included in the query results.

Now that I think about it, you might be able to make a variation of that trick
work. If you go ahead and include the status field in the form's query (even
though it's not displayed), then you could do the updates via the form's
Recordsetclone, then requery the form. Because you're updating data through
the same database instance Access uses for bound form data, there should be no
time lag before the data is available in the data cache, and the requery
should reflect the change. You won't be able to use a transaction to post
changes to multiple details at once, but that shouldn't cause too much
trouble.

re: o2k - more thoughts on moving to multi-user - comments?

Steve Jorgensen <nospam@nospam.nospam> wrote in
news:7oh6d1ha8j3mn3k8v8kvdr0n20219gp6s3@4ax.com:
[color=blue]
> 2. Access sometimes has synchronization issues regarding multiple
> interactions with the same data. Frequently, changes made using
> DAO or ADO in code behind an unbound form will not be displayed in
> a bound form when it is subsequently refreshed or updated without
> first first adding some indeterminate delay. None of the standard
> recommendations for making the problem go away seem to have any
> effect at all. In particular, DBEngine.Idle never seems to have
> any effect.[/color]

Isn't this mostly a problem with server back ends, and not with Jet?
I've never seen a case in my Jet-only applications where a .Refresh
of the display form does not update appropriately.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: o2k - more thoughts on moving to multi-user - comments?

Steve Jorgensen <nospam@nospam.nospam> wrote in
news:2am7d1h3tjvopeh2vldovst341b3bsm0rd@4ax.com:
[color=blue]
> Now that I think about it, you might be able to make a variation
> of that trick work. If you go ahead and include the status field
> in the form's query (even though it's not displayed), then you
> could do the updates via the form's Recordsetclone, then requery
> the form. Because you're updating data through the same database
> instance Access uses for bound form data, there should be no time
> lag before the data is available in the data cache, and the
> requery should reflect the change. You won't be able to use a
> transaction to post changes to multiple details at once, but that
> shouldn't cause too much trouble.[/color]

I've often toyed with the idea in my apps that are deployed in A2K
of having the list form be populated with a recordset, then using
the same recordset in the detail form. I've never quite gotten
around to trying it, though.

Wouldn't that do the trick, as you'd actually be editing the same
data in both forms?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: o2k - more thoughts on moving to multi-user - comments?

On Tue, 12 Jul 2005 22:12:41 GMT, "David W. Fenton"
<dXXXfenton@bway.net.invalid> wrote:
[color=blue]
>Steve Jorgensen <nospam@nospam.nospam> wrote in
>news:2am7d1h3tjvopeh2vldovst341b3bsm0rd@4ax.com :
>[color=green]
>> Now that I think about it, you might be able to make a variation
>> of that trick work. If you go ahead and include the status field
>> in the form's query (even though it's not displayed), then you
>> could do the updates via the form's Recordsetclone, then requery
>> the form. Because you're updating data through the same database
>> instance Access uses for bound form data, there should be no time
>> lag before the data is available in the data cache, and the
>> requery should reflect the change. You won't be able to use a
>> transaction to post changes to multiple details at once, but that
>> shouldn't cause too much trouble.[/color]
>
>I've often toyed with the idea in my apps that are deployed in A2K
>of having the list form be populated with a recordset, then using
>the same recordset in the detail form. I've never quite gotten
>around to trying it, though.
>
>Wouldn't that do the trick, as you'd actually be editing the same
>data in both forms?[/color]

It might, but I'd -really- want to test that because I've found that working
with recordsets both while connected and while unbound form a from, then
hooking them back to a form is a good way to crash Access. I've never tried
the case where a recordset gets passed from one form to another and not
touched while it's unbound - I suspect that might be less problematic than
what I've tried.

re: o2k - more thoughts on moving to multi-user - comments?

On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
<dXXXfenton@bway.net.invalid> wrote:
[color=blue]
>Steve Jorgensen <nospam@nospam.nospam> wrote in
>news:7oh6d1ha8j3mn3k8v8kvdr0n20219gp6s3@4ax.com :
>[color=green]
>> 2. Access sometimes has synchronization issues regarding multiple
>> interactions with the same data. Frequently, changes made using
>> DAO or ADO in code behind an unbound form will not be displayed in
>> a bound form when it is subsequently refreshed or updated without
>> first first adding some indeterminate delay. None of the standard
>> recommendations for making the problem go away seem to have any
>> effect at all. In particular, DBEngine.Idle never seems to have
>> any effect.[/color]
>
>Isn't this mostly a problem with server back ends, and not with Jet?
>I've never seen a case in my Jet-only applications where a .Refresh
>of the display form does not update appropriately.[/color]

There are 2 problems. With a server back-end, there can actually be cases
where data updated through a form is not immediately available on another
form. With a simple Jet back-end, though, there is still a problem where
updates via code may not be immediately available to bound forms and vice
verse.

re: o2k - more thoughts on moving to multi-user - comments?

Steve Jorgensen <nospam@nospam.nospam> wrote in
news:0i59d1pe0j18dbcigv62jamdhmn5ipbred@4ax.com:
[color=blue]
> On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
><dXXXfenton@bway.net.invalid> wrote:
>[color=green]
>>Steve Jorgensen <nospam@nospam.nospam> wrote in
>>news:7oh6d1ha8j3mn3k8v8kvdr0n20219gp6s3@4ax.co m:
>>[color=darkred]
>>> 2. Access sometimes has synchronization issues regarding
>>> multiple interactions with the same data. Frequently, changes
>>> made using DAO or ADO in code behind an unbound form will not be
>>> displayed in a bound form when it is subsequently refreshed or
>>> updated without first first adding some indeterminate delay.
>>> None of the standard recommendations for making the problem go
>>> away seem to have any effect at all. In particular,
>>> DBEngine.Idle never seems to have any effect.[/color]
>>
>>Isn't this mostly a problem with server back ends, and not with
>>Jet? I've never seen a case in my Jet-only applications where a
>>.Refresh of the display form does not update appropriately.[/color]
>
> There are 2 problems. With a server back-end, there can actually
> be cases where data updated through a form is not immediately
> available on another form. With a simple Jet back-end, though,
> there is still a problem where updates via code may not be
> immediately available to bound forms and vice verse.[/color]

Even after a refresh (for updates to existing data) or a requery (to
included newly added records)? I've never seen it, myself.

I don't do much in the way of background updates, but I do often do
adds through DAO, and I've never had a problem getting the data to
show up in the relevant form -- I don't usually requery in that
case, but reset a recordsource.

Actually, I do have some cases where a list form needs to be
requeried to show the added record, but I don't make list forms
editable, in general.

Perhaps that's why I never encounter the problem, because the
architecture I use avoids it entirely.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

re: o2k - more thoughts on moving to multi-user - comments?

On Wed, 13 Jul 2005 22:07:12 GMT, "David W. Fenton"
<dXXXfenton@bway.net.invalid> wrote:
[color=blue]
>Steve Jorgensen <nospam@nospam.nospam> wrote in
>news:0i59d1pe0j18dbcigv62jamdhmn5ipbred@4ax.com :
>[color=green]
>> On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
>><dXXXfenton@bway.net.invalid> wrote:
>>[color=darkred]
>>>Steve Jorgensen <nospam@nospam.nospam> wrote in
>>>news:7oh6d1ha8j3mn3k8v8kvdr0n20219gp6s3@4ax.com :
>>>
>>>> 2. Access sometimes has synchronization issues regarding
>>>> multiple interactions with the same data. Frequently, changes
>>>> made using DAO or ADO in code behind an unbound form will not be
>>>> displayed in a bound form when it is subsequently refreshed or
>>>> updated without first first adding some indeterminate delay.
>>>> None of the standard recommendations for making the problem go
>>>> away seem to have any effect at all. In particular,
>>>> DBEngine.Idle never seems to have any effect.
>>>
>>>Isn't this mostly a problem with server back ends, and not with
>>>Jet? I've never seen a case in my Jet-only applications where a
>>>.Refresh of the display form does not update appropriately.[/color]
>>
>> There are 2 problems. With a server back-end, there can actually
>> be cases where data updated through a form is not immediately
>> available on another form. With a simple Jet back-end, though,
>> there is still a problem where updates via code may not be
>> immediately available to bound forms and vice verse.[/color]
>
>Even after a refresh (for updates to existing data) or a requery (to
>included newly added records)? I've never seen it, myself.
>
>I don't do much in the way of background updates, but I do often do
>adds through DAO, and I've never had a problem getting the data to
>show up in the relevant form -- I don't usually requery in that
>case, but reset a recordsource.
>
>Actually, I do have some cases where a list form needs to be
>requeried to show the added record, but I don't make list forms
>editable, in general.
>
>Perhaps that's why I never encounter the problem, because the
>architecture I use avoids it entirely.[/color]

I've done it many times with no problem at all, and in other apps, I've had to
do battle greatly to work around the problem.

re: o2k - more thoughts on moving to multi-user - comments?

I experience the exact same problem with DAO back end database. I update a
recordset via a form and the result does not show in the sub-form, even
after a requery. I have to close the main form and re-open it (with the
recordset beeing regenerated) to se the result in the sub-form. I have been
experiencing this problem on two different machines (home and office) and
one of my users too. Another user does not exprerience this problem at all
!!!

After so many hours of trying to fix this problem, I have quit working on
it. I would realy appreciate help that could point me to a fix for this
bug.

Michel Boivin
michel at boivin dot net

"David W. Fenton" <dXXXfenton@bway.net.invalid> a écrit dans le message de
news:Xns9692B8559446Adfentonbwaynetinvali@24.168.1 28.90...[color=blue]
> Steve Jorgensen <nospam@nospam.nospam> wrote in
> news:0i59d1pe0j18dbcigv62jamdhmn5ipbred@4ax.com:
>[color=green]
> > On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
> ><dXXXfenton@bway.net.invalid> wrote:
> >[color=darkred]
> >>Steve Jorgensen <nospam@nospam.nospam> wrote in
> >>news:7oh6d1ha8j3mn3k8v8kvdr0n20219gp6s3@4ax.co m:
> >>
> >>> 2. Access sometimes has synchronization issues regarding
> >>> multiple interactions with the same data. Frequently, changes
> >>> made using DAO or ADO in code behind an unbound form will not be
> >>> displayed in a bound form when it is subsequently refreshed or
> >>> updated without first first adding some indeterminate delay.
> >>> None of the standard recommendations for making the problem go
> >>> away seem to have any effect at all. In particular,
> >>> DBEngine.Idle never seems to have any effect.
> >>
> >>Isn't this mostly a problem with server back ends, and not with
> >>Jet? I've never seen a case in my Jet-only applications where a
> >>.Refresh of the display form does not update appropriately.[/color]
> >
> > There are 2 problems. With a server back-end, there can actually
> > be cases where data updated through a form is not immediately
> > available on another form. With a simple Jet back-end, though,
> > there is still a problem where updates via code may not be
> > immediately available to bound forms and vice verse.[/color]
>
> Even after a refresh (for updates to existing data) or a requery (to
> included newly added records)? I've never seen it, myself.
>
> I don't do much in the way of background updates, but I do often do
> adds through DAO, and I've never had a problem getting the data to
> show up in the relevant form -- I don't usually requery in that
> case, but reset a recordsource.
>
> Actually, I do have some cases where a list form needs to be
> requeried to show the added record, but I don't make list forms
> editable, in general.
>
> Perhaps that's why I never encounter the problem, because the
> architecture I use avoids it entirely.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

re: o2k - more thoughts on moving to multi-user - comments?

I experience the exact same problem with DAO back end database. I update a
recordset via a form and the result does not show in the sub-form, even
after a requery. I have to close the main form and re-open it (with the
recordset beeing regenerated) to se the result in the sub-form. I have been
experiencing this problem on two different machines (home and office) and
one of my users too. Another user does not exprerience this problem at all
!!!

After so many hours of trying to fix this problem, I have quit working on
it. I would realy appreciate help that could point me to a fix for this
bug.

Michel Boivin
michel at boivin dot net

"David W. Fenton" <dXXXfenton@bway.net.invalid> a écrit dans le message de
news:Xns9692B8559446Adfentonbwaynetinvali@24.168.1 28.90...[color=blue]
> Steve Jorgensen <nospam@nospam.nospam> wrote in
> news:0i59d1pe0j18dbcigv62jamdhmn5ipbred@4ax.com:
>[color=green]
> > On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
> ><dXXXfenton@bway.net.invalid> wrote:
> >[color=darkred]
> >>Steve Jorgensen <nospam@nospam.nospam> wrote in
> >>news:7oh6d1ha8j3mn3k8v8kvdr0n20219gp6s3@4ax.co m:
> >>
> >>> 2. Access sometimes has synchronization issues regarding
> >>> multiple interactions with the same data. Frequently, changes
> >>> made using DAO or ADO in code behind an unbound form will not be
> >>> displayed in a bound form when it is subsequently refreshed or
> >>> updated without first first adding some indeterminate delay.
> >>> None of the standard recommendations for making the problem go
> >>> away seem to have any effect at all. In particular,
> >>> DBEngine.Idle never seems to have any effect.
> >>
> >>Isn't this mostly a problem with server back ends, and not with
> >>Jet? I've never seen a case in my Jet-only applications where a
> >>.Refresh of the display form does not update appropriately.[/color]
> >
> > There are 2 problems. With a server back-end, there can actually
> > be cases where data updated through a form is not immediately
> > available on another form. With a simple Jet back-end, though,
> > there is still a problem where updates via code may not be
> > immediately available to bound forms and vice verse.[/color]
>
> Even after a refresh (for updates to existing data) or a requery (to
> included newly added records)? I've never seen it, myself.
>
> I don't do much in the way of background updates, but I do often do
> adds through DAO, and I've never had a problem getting the data to
> show up in the relevant form -- I don't usually requery in that
> case, but reset a recordsource.
>
> Actually, I do have some cases where a list form needs to be
> requeried to show the added record, but I don't make list forms
> editable, in general.
>
> Perhaps that's why I never encounter the problem, because the
> architecture I use avoids it entirely.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]