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

[Deano]

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

[Deano]

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

--

[Steve Jorgensen]

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" <de***@mailinator.com> wrote:

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

[Deano]

Steve Jorgensen wrote:

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.

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

[Deano]

Deano wrote:

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.

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.

--

[Steve Jorgensen]

On Mon, 11 Jul 2005 20:24:21 +0100, "Deano" <de***@mailinator.com> wrote:

Deano wrote:

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.

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.

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.

[Deano]

Steve Jorgensen wrote:

On Mon, 11 Jul 2005 20:24:21 +0100, "Deano" <de***@mailinator.com>
wrote:

Deano wrote:

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

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.

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.

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.

And now you scare me again Steve :)

--

[Steve Jorgensen]

On Tue, 12 Jul 2005 11:25:37 +0100, "Deano" <de***@mailinator.com> wrote:

Steve Jorgensen wrote:

On Mon, 11 Jul 2005 20:24:21 +0100, "Deano" <de***@mailinator.com>
wrote:
.... 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.

And now you scare me again Steve :)

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.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:7o********************************@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.

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

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:2a********************************@4ax.com:

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.

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

[Steve Jorgensen]

On Tue, 12 Jul 2005 22:12:41 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:2a********************************@4ax.com :

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.

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?

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.

[Steve Jorgensen]

On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:7o********************************@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.

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.

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.com:

On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:7o********************************@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.

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.

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

[Steve Jorgensen]

On Wed, 13 Jul 2005 22:07:12 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.com :

On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:7o********************************@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.

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.

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.

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.

[Michel Boivin, ing.]

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" <dX********@bway.net.invalid> a écrit dans le message de
news:Xn**********************************@24.168.1 28.90...

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.com:

On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:7o********************************@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.

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.

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

[Michel Boivin, ing.]

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" <dX********@bway.net.invalid> a écrit dans le message de
news:Xn**********************************@24.168.1 28.90...

Steve Jorgensen <no****@nospam.nospam> wrote in
news:0i********************************@4ax.com:

On Tue, 12 Jul 2005 22:10:07 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:7o********************************@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.

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.

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