Desire to REMERGE Database and Program!!

[Peter Miller]

Re: Desire to REMERGE Database and Program!!


Heather,

On Wed, 12 Nov 2003 18:26:18 GMT, "Heather"
<hamonroe@csedu cationalsystems .org> wrote in comp.databases. ms-access:
[color=blue]
>I have a central split database maintained by two admins. I'm going to need to
>need to send a copy of the database to six remote sites monthly on CD.[/color]

Not an unusual situation.
[color=blue]
>Via code
>I would like to merge the FE and BE and then copy to CD. This makes copying to
>CD easier[/color]

...because two files are a LOT harder to write to cd than one? Please.
[color=blue]
>but more so makes the installation at the remote sites simpler. I want
>to include the FE each month so that if changes are ever made to the central
>database they will be included in the monthly distributions. The need is for
>push button operation for the admins and especially for the remote sites.[/color]

The only 'problem' with installation of a fe/be setup vs single file
setup at the remote site is to update the table links. This is a LOT
easier and faster to do in code than to merge the two files.
Refreshing links takes seconds. Importing tables into your fe, then
distributing an all-in-one file is simply a bad idea. There are no
reasons why this would improve your job, the local admins jobs, or the
work required or stability/performance delivered at the remote site.
You're simply tackling the wrong problem.

I don't know if David is toying with you by offering code that does
what you ask for even if what you ask for is am ill-conceived idea,
but rather than defining the problem narrowly as a lack of code to
automate a merge, you really should be thinking about why you're
trying to do this in the first place and whether you're headed down
the wrong path.


Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Heather]

Re: Desire to REMERGE Database and Program!!

Peter,

Are you recommending just to copy both files(FE and BE) to a CD and distribute
to each remote location? Why would the links need refreshed if done this way?

Heather


"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:cf35rvg8ur 01hl8mchcn17erh 5lvpva4lj@4ax.c om...[color=blue]
>
> Heather,
>
> On Wed, 12 Nov 2003 18:26:18 GMT, "Heather"
> <hamonroe@csedu cationalsystems .org> wrote in comp.databases. ms-access:
>[color=green]
> >I have a central split database maintained by two admins. I'm going to need[/color][/color]
to[color=blue][color=green]
> >need to send a copy of the database to six remote sites monthly on CD.[/color]
>
> Not an unusual situation.
>[color=green]
> >Via code
> >I would like to merge the FE and BE and then copy to CD. This makes copying[/color][/color]
to[color=blue][color=green]
> >CD easier[/color]
>
> ..because two files are a LOT harder to write to cd than one? Please.
>[color=green]
> >but more so makes the installation at the remote sites simpler. I want
> >to include the FE each month so that if changes are ever made to the central
> >database they will be included in the monthly distributions. The need is for
> >push button operation for the admins and especially for the remote sites.[/color]
>
> The only 'problem' with installation of a fe/be setup vs single file
> setup at the remote site is to update the table links. This is a LOT
> easier and faster to do in code than to merge the two files.
> Refreshing links takes seconds. Importing tables into your fe, then
> distributing an all-in-one file is simply a bad idea. There are no
> reasons why this would improve your job, the local admins jobs, or the
> work required or stability/performance delivered at the remote site.
> You're simply tackling the wrong problem.
>
> I don't know if David is toying with you by offering code that does
> what you ask for even if what you ask for is am ill-conceived idea,
> but rather than defining the problem narrowly as a lack of code to
> automate a merge, you really should be thinking about why you're
> trying to do this in the first place and whether you're headed down
> the wrong path.
>
>
> Peter Miller
> _______________ _______________ _______________ _______________
> PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
> Free quotes, Guaranteed lowest prices and best results
> www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051[/color]

[Peter Miller]

Re: Desire to REMERGE Database and Program!!



Heather,

On Wed, 12 Nov 2003 20:44:16 GMT, "Heather"
<hamonroe@csedu cationalsystems .org> wrote in comp.databases. ms-access:
[color=blue]
>Are you recommending just to copy both files(FE and BE) to a CD and distribute
>to each remote location? Why would the links need refreshed if done this way?[/color]

Because, unless the exact path for the BE is the same on all six
systems, the FE won't work. Simply placing FE and BE in the same
folder won't work if that folder has a different name or location on
the six systems. Of course, you could force all six locations to
place the be at the exact same location as your site (ie, c:\mydata or
z:\mydata if on the network and all systems can use the same available
drive letter for mapping), but this is not desirable.

The best approach is to simply have the fe's links refreshed to point
to the be, at whatever its new location is at the six sites. This
could be done in seconds manually, or it could be done even faster by
code.

Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[John Baker]

Re: Desire to REMERGE Database and Program!!

To everyone:

Thanks for your advice and suggestions, and everything. I am a relative newby to the
Access world (Used Lotus Approach for years and loved it till it fell out of favor with
management). Your thoughs are most helpful. I did not realize I would stimulate such a
response.

Regards

John

[Heather]

Re: Desire to REMERGE Database and Program!!

Peter,

Thank you for staying with me!

How does refreshing know where the BE is at?

Could you share some code to have the fe's links refreshed to point
to the be, at whatever its new location.

Thanks for your help!

Heather


"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:2bc5rv02oe cjiv75lra64603a uqaglfo3d@4ax.c om...[color=blue]
>
>
> Heather,
>
> On Wed, 12 Nov 2003 20:44:16 GMT, "Heather"
> <hamonroe@csedu cationalsystems .org> wrote in comp.databases. ms-access:
>[color=green]
> >Are you recommending just to copy both files(FE and BE) to a CD and[/color][/color]
distribute[color=blue][color=green]
> >to each remote location? Why would the links need refreshed if done this way?[/color]
>
> Because, unless the exact path for the BE is the same on all six
> systems, the FE won't work. Simply placing FE and BE in the same
> folder won't work if that folder has a different name or location on
> the six systems. Of course, you could force all six locations to
> place the be at the exact same location as your site (ie, c:\mydata or
> z:\mydata if on the network and all systems can use the same available
> drive letter for mapping), but this is not desirable.
>
> The best approach is to simply have the fe's links refreshed to point
> to the be, at whatever its new location is at the six sites. This
> could be done in seconds manually, or it could be done even faster by
> code.
>
> Peter Miller
> _______________ _______________ _______________ _______________
> PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
> Free quotes, Guaranteed lowest prices and best results
> www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051[/color]

[Peter Miller]

Re: Desire to REMERGE Database and Program!!


Heather,

On Wed, 12 Nov 2003 22:39:45 GMT, "Heather"
<hamonroe@csedu cationalsystems .org> wrote in comp.databases. ms-access:
[color=blue]
>Thank you for staying with me![/color]

No problem.
[color=blue]
>How does refreshing know where the BE is at?[/color]

Refreshing doesn't. If its done manually, it would involve simply
opening the file, go to Tools/DatabaseUtiliti es/LinkedTableMAna ger and
then enabling 'always prompt for new location', choosing 'select all'
and then pointing to the be in the current directory.
[color=blue]
>Could you share some code to have the fe's links refreshed to point
>to the be, at whatever its new location.[/color]

Well, sure, but this is aircode...

sub localbeupdate
dim f$, t as dao.tabledef 'assumes dao is referenced
f = currentdb.name
f = left(f,instr(f, "\fe_name.mdb") ) & "\be_name.m db"
for each t in currentdb.table defs
if t.connect<>"" then
t.connect=";dat abase=" & f
t.refreshlink
end if
next t
set t = nothing
end sub

....with fe_name.mdb and be_name.mdb being the file names of the fe and
be, both of which are copied to the same directory (doesn't matter
what its called or where it is). You'd want to make sure the
read-only flag on the files is set to false (since you're copying off
a cd) and you'd want to reference dao in the code and call this
routine on startup. You could set a flag in the fe to indicate
whether its a remote version or not (so you wouldn't be auto-relinking
on the main core files at your site).

hth,



Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Heather]

Re: Desire to REMERGE Database and Program!!

Thanks, Peter, you have helped me a lot. I appreciate it.

Heather


"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:6od5rvkfnp j7s12190ovjnvge ftscg6250@4ax.c om...[color=blue]
>
> Heather,
>
> On Wed, 12 Nov 2003 22:39:45 GMT, "Heather"
> <hamonroe@csedu cationalsystems .org> wrote in comp.databases. ms-access:
>[color=green]
> >Thank you for staying with me![/color]
>
> No problem.
>[color=green]
> >How does refreshing know where the BE is at?[/color]
>
> Refreshing doesn't. If its done manually, it would involve simply
> opening the file, go to Tools/DatabaseUtiliti es/LinkedTableMAna ger and
> then enabling 'always prompt for new location', choosing 'select all'
> and then pointing to the be in the current directory.
>[color=green]
> >Could you share some code to have the fe's links refreshed to point
> >to the be, at whatever its new location.[/color]
>
> Well, sure, but this is aircode...
>
> sub localbeupdate
> dim f$, t as dao.tabledef 'assumes dao is referenced
> f = currentdb.name
> f = left(f,instr(f, "\fe_name.mdb") ) & "\be_name.m db"
> for each t in currentdb.table defs
> if t.connect<>"" then
> t.connect=";dat abase=" & f
> t.refreshlink
> end if
> next t
> set t = nothing
> end sub
>
> ...with fe_name.mdb and be_name.mdb being the file names of the fe and
> be, both of which are copied to the same directory (doesn't matter
> what its called or where it is). You'd want to make sure the
> read-only flag on the files is set to false (since you're copying off
> a cd) and you'd want to reference dao in the code and call this
> routine on startup. You could set a flag in the fe to indicate
> whether its a remote version or not (so you wouldn't be auto-relinking
> on the main core files at your site).
>
> hth,
>
>
>
> Peter Miller
> _______________ _______________ _______________ _______________
> PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
> Free quotes, Guaranteed lowest prices and best results
> www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051[/color]

[David W. Fenton]

Re: Desire to REMERGE Database and Program!!

pmiller@pksolut ions.com (Peter Miller) wrote in
<cf35rvg8ur01hl 8mchcn17erh5lvp va4lj@4ax.com>:
[color=blue]
>I don't know if David is toying with you by offering code that
>does what you ask for even if what you ask for is am ill-conceived
>idea, but rather than defining the problem narrowly as a lack of
>code to automate a merge, you really should be thinking about why
>you're trying to do this in the first place and whether you're
>headed down the wrong path.[/color]

I'm not toying with her.

There is everyone reason that one might need to delete links and
recreate them, such as the A2K problem with slow links because of
certain kinds of cached data.

Regardless of whether or not you think what she's doing is a good
idea or not, no one was giving the basic principles about how to do
it.

And based on her explanation, I don't think it's necessarily a bad
idea. Seemed to me the situation was one where there was no benefit
from a split architecture, as it sounded like single user, and
there was no need to keep old data. Maybe I mis-read it, but it
seemed perfectly logical.

Yes, code to automatically reconnect to data tables in an MDB in
the same folder as the MDB is pretty easy to find.

But that's got its own potential problems, as well, and may not be
worth it for the purposes she asked the question.

Clearly, since she's starting from a split architecture she
understands how it works and what it's good for. Given that, I
don't feel it's my job to say "hey, you don't know what you're
doing."

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

[Tom Wickerath]

Re: Desire to REMERGE Database and Program!!

To John, Heather, Peter, & David (and anyone else who may be interested):

About a year and a half ago(?), I talked with Scott Barker on the phone. For those who
don't know, Scott is a former member of the Access development team at Microsoft, has
written several books on Access, travels the world talking to various groups about Access
& .Net topics, etc. During our conversation, he mentioned that he included sample code on
the CD that comes with his Access 2002 Power Programming book to do exactly what Heather
wants to accomplish: ie. to programmaticall y pull the back-end tables into the front-end
database. I believe his code also reverses the situation, so that one can automatically
return the database to its FE-BE configuration, with refreshed links. However, his code
was designed to work with a single back-end database only. The person I was helping at
the time, who wanted this capability, had links to about 4 or 5 separate back-end
databases.

I cannot say that I have tried his sample out, because so far I haven't purchased the 2002
copy of his book. (I have the versions that were written for Access 97 & 2000, but he
said that this was something new he added to the 2002 version).

Peter: I guess a good question for you is why are you so adamant that this is not
something that one might want to do, given that a rather talented developer in the
database field as smart and skilled as Scott Barker has chosen to do just this very thing?

Heather: Buy Scott's book and you'll have a tested and thoroughly debugged method ready to
go, "off the shelf". I'm guessing that he has included the same sample in his Access 2003
version of Power Programming, but you might want to verify that with him first.

Tom Wickerath
_______________ _______________ ___________

"John Baker" <Baker.JH@Veriz on.net> wrote in message
news:mjd5rv8vlu gfek3giofqi0s0d eb5c38nnc@4ax.c om...
To everyone:

Thanks for your advice and suggestions, and everything. I am a relative newby to the
Access world (Used Lotus Approach for years and loved it till it fell out of favor with
management). Your thoughs are most helpful. I did not realize I would stimulate such a
response.

Regards

John

[Peter Miller]

Re: Desire to REMERGE Database and Program!!


Tom,

On Wed, 12 Nov 2003 22:40:56 -0800, "Tom Wickerath"
<AOS168RemoveTh isSpamBlock@com cast.net> wrote in
comp.databases. ms-access:
[color=blue]
>Peter: I guess a good question for you is why are you so adamant that this is not
>something that one might want to do, given that a rather talented developer in the
>database field as smart and skilled as Scott Barker has chosen to do just this very thing?[/color]

Perhaps a good question for you is why you need me to weigh in on the
pros and cons of this, rather than simply thinking it through based on
what you know of Access. I'd strongly suggest taking that approach
rather than trying to work out which developers are the smartest, then
just doing what they suggest blindly.

Let's take a look at the problem as its been detailed so far.

A FE/BE implementation is already in use (kudo's, Heather) and working
fine. Six remote sites need offline access to this application, and
Heather is looking to make the process of transferring and using these
files as easy as possible. We do not know whether there will be one,
or more than one user at each remote site.

The problem, as originally described, was to be solved by merging the
FE and BE into one file, and distributing it to the six locations. We
know that if this is done, the file will be sub-optimal if more than
one user users the application at each site. We also know that
Heather will need to write or copy code to effect this merge, and
execute it every time the distribution is to be made. We don't know
how big the backend is, but every time the files are to go out, all
the data will have to be written into either the FE or a new file. If
the db is large, it will take some time (probably not too much).

Now I suggested that Heather not waste her time looking for or writing
code (trivial as it may be) that will import tables every
week/month/whatever, and that she simply send out her current fe/be
pair with no processing required. We know that regardless of how many
users wish to use the application at each site, the application will
be in its recommended state. The sole 'problem' then becomes how to
refresh the already existing links in the FE. This is trivial, code
was provided, and it takes less time than importing tables and data.

Now which approach do YOU think is preferable? Just because code is
written and provided in a book does not mean it is appropriate for
every situation. I'd be very interested if you could tell me why on
earth you would suggest using it in this one, because frankly, I can't
see how it would make any sense.


Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Tom Wickerath]

Re: Desire to REMERGE Database and Program!!

> Perhaps a good question for you is why you need me to weigh in on the[color=blue]
> pros and cons of this, rather than simply thinking it through based on
> what you know of Access. I'd strongly suggest taking that approach
> rather than trying to work out which developers are the smartest, then
> just doing what they suggest blindly.[/color]

Obviously, I have not followed this suggestion blindly. Otherwise, I would have run out to
my local bookstore and picked up a copy of the book. The point I was trying to make is
that there may very well be legitimate reasons for doing so. You are the one who jumped
to the conclusion that this was an "ill-conceived idea", suggested that David might be
"toying" with Heather by offering some code, and implied that someone is "headed down the
wrong path". It seems to me like you're strongly suggesting that everyone blindly agree
with your opinion without dissent. In the interest of being "fair and balanced", I
thought people should be aware of Scott's sample. Let them make up their own mind once
they have all the facts and data.
[color=blue]
> I'd be very interested if you could tell me why on earth you would
> suggest using it in this one, because frankly, I can't see how it
> would make any sense.[/color]

Simple. Scott mentioned that this allows him to take a copy of a database quickly, move
it to his PC and work on it (no time required to re-link at this point, since the tables
are local). At the start of the following business day, he can return the database to its
original condition with the click of a single command button on a form. This includes
returning the linked paths to their original UNC named paths, since his solution stores
the UNC path.
[color=blue]
> Of course, you could force all six locations to place the be at the
> exact same location as your site (ie, c:\mydata or z:\mydata if on
> the network and all systems can use the same available drive letter
> for mapping), but this is not desirable.[/color]

Here, I think we can agree. Including a hard-coded drive letter in the linked path is not
desirable, and anyone who does so is only asking for trouble! Scott's solution allows
one to restore a UNC path with a single click of a command button. (Okay, maybe two
clicks--one to open the form, and one to click on the button). Two clicks and its all
done. What could be simpler? No need to use a common dialog box, whether via ActiveX
control or API call, to navigate to the correct BE folder, no need to type in the UNC
path, etc.

_______________ _______________ _______________ __

"Peter Miller" <pmiller@pksolu tions.com> wrote in message
news:era6rv8kgb ad5sgge4ds5nml2 hesm7e9h9@4ax.c om...

Tom,

On Wed, 12 Nov 2003 22:40:56 -0800, "Tom Wickerath"
<AOS168RemoveTh isSpamBlock@com cast.net> wrote in
comp.databases. ms-access:
[color=blue]
>Peter: I guess a good question for you is why are you so adamant that this is not
>something that one might want to do, given that a rather talented developer in the
>database field as smart and skilled as Scott Barker has chosen to do just this very[/color]
thing?

Perhaps a good question for you is why you need me to weigh in on the
pros and cons of this, rather than simply thinking it through based on
what you know of Access. I'd strongly suggest taking that approach
rather than trying to work out which developers are the smartest, then
just doing what they suggest blindly.

Let's take a look at the problem as its been detailed so far.

A FE/BE implementation is already in use (kudo's, Heather) and working
fine. Six remote sites need offline access to this application, and
Heather is looking to make the process of transferring and using these
files as easy as possible. We do not know whether there will be one,
or more than one user at each remote site.

The problem, as originally described, was to be solved by merging the
FE and BE into one file, and distributing it to the six locations. We
know that if this is done, the file will be sub-optimal if more than
one user users the application at each site. We also know that
Heather will need to write or copy code to effect this merge, and
execute it every time the distribution is to be made. We don't know
how big the backend is, but every time the files are to go out, all
the data will have to be written into either the FE or a new file. If
the db is large, it will take some time (probably not too much).

Now I suggested that Heather not waste her time looking for or writing
code (trivial as it may be) that will import tables every
week/month/whatever, and that she simply send out her current fe/be
pair with no processing required. We know that regardless of how many
users wish to use the application at each site, the application will
be in its recommended state. The sole 'problem' then becomes how to
refresh the already existing links in the FE. This is trivial, code
was provided, and it takes less time than importing tables and data.

Now which approach do YOU think is preferable? Just because code is
written and provided in a book does not mean it is appropriate for
every situation. I'd be very interested if you could tell me why on
earth you would suggest using it in this one, because frankly, I can't
see how it would make any sense.


Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Lyle Fairfield]

Re: Desire to REMERGE Database and Program!!

"Tom Wickerath" <AOS168RemoveTh isSpamBlock@com cast.net> wrote in
news:EcidnUmnnL 3pui6iRVn-uA@comcast.com:
[color=blue]
> To John, Heather, Peter, & David (and anyone else who may be
> interested):
>
> About a year and a half ago(?), I talked with Scott Barker on the phone.
> For those who don't know, Scott is a former member of the Access
> development team at Microsoft, has written several books on Access,
> travels the world talking to various groups about Access & .Net topics,
> etc. During our conversation, he mentioned that he included sample code
> on the CD that comes with his Access 2002 Power Programming book to do
> exactly what Heather wants to accomplish: ie. to programmaticall y pull
> the back-end tables into the front-end database. I believe his code
> also reverses the situation, so that one can automatically return the
> database to its FE-BE configuration, with refreshed links. However, his
> code was designed to work with a single back-end database only. The
> person I was helping at the time, who wanted this capability, had links
> to about 4 or 5 separate back-end databases.[/color]

ROFL! Nonsense is nonsense; it doesn't matter who says it. And this is
nonsense.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Terry Kreft]

Re: Desire to REMERGE Database and Program!!

.... But if instead he had simply copied the FE/BE to the desired location
and had the FE search for the BE when it was opened and refresh the links he
wouldn't even have to do the 1/2/3 clicks you describe, it would just work
and at the end of the day that's what most users want, for it to just work.


I agree with Peter on this one remerging the DB is sub-optimal.


Terry



"Tom Wickerath" <AOS168RemoveTh isSpamBlock@com cast.net> wrote in message
news:ArydnVPD_Y p8yi6iRVn-jA@comcast.com. ..[color=blue][color=green]
> > Perhaps a good question for you is why you need me to weigh in on the
> > pros and cons of this, rather than simply thinking it through based on
> > what you know of Access. I'd strongly suggest taking that approach
> > rather than trying to work out which developers are the smartest, then
> > just doing what they suggest blindly.[/color]
>
> Obviously, I have not followed this suggestion blindly. Otherwise, I would[/color]
have run out to[color=blue]
> my local bookstore and picked up a copy of the book. The point I was[/color]
trying to make is[color=blue]
> that there may very well be legitimate reasons for doing so. You are the[/color]
one who jumped[color=blue]
> to the conclusion that this was an "ill-conceived idea", suggested that[/color]
David might be[color=blue]
> "toying" with Heather by offering some code, and implied that someone is[/color]
"headed down the[color=blue]
> wrong path". It seems to me like you're strongly suggesting that everyone[/color]
blindly agree[color=blue]
> with your opinion without dissent. In the interest of being "fair and[/color]
balanced", I[color=blue]
> thought people should be aware of Scott's sample. Let them make up their[/color]
own mind once[color=blue]
> they have all the facts and data.
>[color=green]
> > I'd be very interested if you could tell me why on earth you would
> > suggest using it in this one, because frankly, I can't see how it
> > would make any sense.[/color]
>
> Simple. Scott mentioned that this allows him to take a copy of a database[/color]
quickly, move[color=blue]
> it to his PC and work on it (no time required to re-link at this point,[/color]
since the tables[color=blue]
> are local). At the start of the following business day, he can return the[/color]
database to its[color=blue]
> original condition with the click of a single command button on a form.[/color]
This includes[color=blue]
> returning the linked paths to their original UNC named paths, since his[/color]
solution stores[color=blue]
> the UNC path.
>[color=green]
> > Of course, you could force all six locations to place the be at the
> > exact same location as your site (ie, c:\mydata or z:\mydata if on
> > the network and all systems can use the same available drive letter
> > for mapping), but this is not desirable.[/color]
>
> Here, I think we can agree. Including a hard-coded drive letter in the[/color]
linked path is not[color=blue]
> desirable, and anyone who does so is only asking for trouble! Scott's[/color]
solution allows[color=blue]
> one to restore a UNC path with a single click of a command button. (Okay,[/color]
maybe two[color=blue]
> clicks--one to open the form, and one to click on the button). Two clicks[/color]
and its all[color=blue]
> done. What could be simpler? No need to use a common dialog box, whether[/color]
via ActiveX[color=blue]
> control or API call, to navigate to the correct BE folder, no need to type[/color]
in the UNC[color=blue]
> path, etc.
>
> _______________ _______________ _______________ __
>
> "Peter Miller" <pmiller@pksolu tions.com> wrote in message
> news:era6rv8kgb ad5sgge4ds5nml2 hesm7e9h9@4ax.c om...
>
> Tom,
>
> On Wed, 12 Nov 2003 22:40:56 -0800, "Tom Wickerath"
> <AOS168RemoveTh isSpamBlock@com cast.net> wrote in
> comp.databases. ms-access:
>[color=green]
> >Peter: I guess a good question for you is why are you so adamant that[/color][/color]
this is not[color=blue][color=green]
> >something that one might want to do, given that a rather talented[/color][/color]
developer in the[color=blue][color=green]
> >database field as smart and skilled as Scott Barker has chosen to do just[/color][/color]
this very[color=blue]
> thing?
>
> Perhaps a good question for you is why you need me to weigh in on the
> pros and cons of this, rather than simply thinking it through based on
> what you know of Access. I'd strongly suggest taking that approach
> rather than trying to work out which developers are the smartest, then
> just doing what they suggest blindly.
>
> Let's take a look at the problem as its been detailed so far.
>
> A FE/BE implementation is already in use (kudo's, Heather) and working
> fine. Six remote sites need offline access to this application, and
> Heather is looking to make the process of transferring and using these
> files as easy as possible. We do not know whether there will be one,
> or more than one user at each remote site.
>
> The problem, as originally described, was to be solved by merging the
> FE and BE into one file, and distributing it to the six locations. We
> know that if this is done, the file will be sub-optimal if more than
> one user users the application at each site. We also know that
> Heather will need to write or copy code to effect this merge, and
> execute it every time the distribution is to be made. We don't know
> how big the backend is, but every time the files are to go out, all
> the data will have to be written into either the FE or a new file. If
> the db is large, it will take some time (probably not too much).
>
> Now I suggested that Heather not waste her time looking for or writing
> code (trivial as it may be) that will import tables every
> week/month/whatever, and that she simply send out her current fe/be
> pair with no processing required. We know that regardless of how many
> users wish to use the application at each site, the application will
> be in its recommended state. The sole 'problem' then becomes how to
> refresh the already existing links in the FE. This is trivial, code
> was provided, and it takes less time than importing tables and data.
>
> Now which approach do YOU think is preferable? Just because code is
> written and provided in a book does not mean it is appropriate for
> every situation. I'd be very interested if you could tell me why on
> earth you would suggest using it in this one, because frankly, I can't
> see how it would make any sense.
>
>
> Peter Miller
> _______________ _______________ _______________ _______________
> PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
> Free quotes, Guaranteed lowest prices and best results
> www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051
>
>[/color]

[Terry Kreft]

Re: Desire to REMERGE Database and Program!!

Lyle,

I think you meant ... (go to bottom)
"Lyle Fairfield" <MissingAddress @Invalid.Com> wrote in message
news:Xns94323F5 5CEC10FFDBA@130 .133.1.4...[color=blue]
> "Tom Wickerath" <AOS168RemoveTh isSpamBlock@com cast.net> wrote in
> news:EcidnUmnnL 3pui6iRVn-uA@comcast.com:
>[color=green]
> > To John, Heather, Peter, & David (and anyone else who may be
> > interested):
> >
> > About a year and a half ago(?), I talked with Scott Barker on the phone.
> > For those who don't know, Scott is a former member of the Access
> > development team at Microsoft, has written several books on Access,
> > travels the world talking to various groups about Access & .Net topics,
> > etc. During our conversation, he mentioned that he included sample code
> > on the CD that comes with his Access 2002 Power Programming book to do
> > exactly what Heather wants to accomplish: ie. to programmaticall y pull
> > the back-end tables into the front-end database. I believe his code
> > also reverses the situation, so that one can automatically return the
> > database to its FE-BE configuration, with refreshed links. However, his
> > code was designed to work with a single back-end database only. The
> > person I was helping at the time, who wanted this capability, had links
> > to about 4 or 5 separate back-end databases.[/color]
>
> ROFL! Nonsense is nonsense; it doesn't matter who says it. And this is
> nonsense.
>
> --
> Lyle
> (for e-mail refer to http://ffdba.com/contacts.htm)[/color]

.... and the above is nonsense <g>.


Terry

[Peter Miller]

Re: Desire to REMERGE Database and Program!!


Tom,

On Thu, 13 Nov 2003 02:07:43 -0800, "Tom Wickerath"
<AOS168RemoveTh isSpamBlock@com cast.net> wrote in
comp.databases. ms-access:
[color=blue][color=green]
>> Perhaps a good question for you is why you need me to weigh in on the
>> pros and cons of this, rather than simply thinking it through based on
>> what you know of Access. I'd strongly suggest taking that approach
>> rather than trying to work out which developers are the smartest, then
>> just doing what they suggest blindly.[/color]
>
>Obviously, I have not followed this suggestion blindly. Otherwise, I would have run out to
>my local bookstore and picked up a copy of the book. The point I was trying to make is
>that there may very well be legitimate reasons for doing so.[/color]

I didn't mean to suggest that you 'had' followed someone blindly -
just that you were comparing person a to person b rather than simply
discussing the merits yourself. You specifically said Scott's a smart
guy and he says 'x' but you say 'y'. But you never compared 'x' and
'y' yourself - at least not in your post. If you did compare the two
outside of the post, why didn't your post reflect *your* view of the
pros and cons of each, or simply why you preferred 'x'?
[color=blue]
>You are the one who jumped
>to the conclusion that this was an "ill-conceived idea",[/color]

I didn't 'jump' to any conclusion. I considered the merits, and
explained why my conclusion was better. I'll say it again. There is
no reason to copy the BE tables to the fe before shipping rather than
simply bypassing this step altogether and shipping the BE too. It's a
stupid step that not a single person in this thread has provided any
argument for, because none exists. If you ask Scott, I don't doubt
for a second that he would consider, upon reflection, that copying the
BE tables to the FE was a superfluous step, and had he to do it again,
his code wouldn't have wasted time with this aspect.

I've already listed the advantages of simply using the existing
backend in a prior post, but they should be obvious.
[color=blue]
>suggested that David might be "toying" with Heather by offering some code,[/color]

I meant no offense by that remark. David gave Heather exactly what
she asked for. It's just that I'm quite confident that David would
not have solved this problem in this fashion if he was the one seeking
to work on the fe/be pair offsite, so giving someone a solution they
ask for when that solution is not one that you would use were you to
have the same problem is, I think, a playful response. Nothing wrong
in that, but I don't think its as helpful to the OP as simply telling
them why their question is the wrong question, and providing an answer
more in line with how you *would* solve the problem yourself.
[color=blue]
>and implied that someone is "headed down the wrong path".[/color]

It's not just an implication. I'll say it emphatically. Heather
*was* heading down the wrong path.
[color=blue]
> It seems to me like you're strongly suggesting that everyone blindly agree
>with your opinion without dissent.[/color]

Huh? Not at all. I'm LOOKING for anyone who 'dissents' (as you put
it) to actually provide an argument for their case, but I haven't
found it. I'll ask you again. Why does it make sense to you to move
the tables to the front-end before shipping and back to the backend
upon return, rather than simply taking the backend with you?
[color=blue]
>In the interest of being "fair and balanced", I
>thought people should be aware of Scott's sample. Let them make up their own mind once
>they have all the facts and data.[/color]

Its funny that you use 'fair and balanced' in quotes here since the
Fox mindset is exactly what I'm trying to oppose (ie, "dumb it down,
keep it simple, people will lap it up"... rather than using one's own
mind to evaluate the pros and cons of a given situation, and making
one's own decision based on the actual merits rather than the
personalities involved).

Well, I'm all for them taking a look at any other solutions. But you
still have to evaluate those solutions on their merits.
[color=blue][color=green]
>> I'd be very interested if you could tell me why on earth you would
>> suggest using it in this one, because frankly, I can't see how it
>> would make any sense.[/color]
>
>Simple. Scott mentioned that this allows him to take a copy of a database quickly, move
>it to his PC and work on it (no time required to re-link at this point, since the tables
>are local). At the start of the following business day, he can return the database to its
>original condition with the click of a single command button on a form. This includes
>returning the linked paths to their original UNC named paths, since his solution stores
>the UNC path.[/color]

And, again, we're skipping the comparison...

So Scott's code allows him to copy a file quickly? How quickly? His
code must copy any and all tables into another file. This doesn't
take forever, but it certainly is nowhere near as fast as having to do
NOTHING AT ALL before he leaves work other than to simply take the
fe/be pair with him, right?

And when he returns to work, he needs to AGAIN copy the tables from
the merged file back to their original be locations. Another step
that can be skipped by keeping the files separate.

You point out that keeping the files as a pair requires relinking at
the remote site, which is true, but takes no time at all - certainly
much less than coping each table in it's entirety TWICE.

The only merit in his approach that wasn't previously discussed, and
handled in a better fashion in this thread, was the storage of UNC
paths. However, this is as easy to incorporate in the fe/be pair
approach as in the single file approach, and is completely independent
of whether the BE data is moved to the FE vs whether links are simply
refreshed.

I'm not saying Scott's code doesn't work or shouldn't be used, but
rather that there is no reason why it would be better, on any level,
than copying the fe/be pair and taking them both home or to the remote
site, and simply having the code switch links (yes, storing the UNC
path so links to multiple files can be restored correctly).

I'm not asking people to agree with me. I'm asking them to think
about the problem. If anyone out there can put forth any reason why
it would make sense to move the data to the front-end instead of
simply taking the back-end with you, by all means, please chime in
with it, because nobody to this point has done so.

That said, this really is an unimportant issue. If Heather wants to
copy data back and forth between FE and BE unnecessarily, she should
by all means do so. Her app won't crash (although, if lots of users
are to share the app on any remote site, sharing a single mdb *will*
indeed increase the chance of corruption vs using a fe/be pair). What
gets me is not that this issue is critical (it's certainly not) but
that people are suggesting bad (but, if narrowly defined, apt)
solutions to a bad question without any analysis or thought as to what
the appropriate, and easier, solution would be.


Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051