473,321 Members | 1,877 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

Desire to REMERGE Database and Program!!

Hi:

Some time ago I developed a program in Access, and separated the database and the program
itself (using the normal access tools).We have the db on our server and the programin the
desktop system. I have modified the program a number of times, and now find that I need
to change the DB slightlt. This appears to require that I REMERGE the data base and
program, and I have no idea how to do that.

Can someone give me some pointers, since the help package is of NO help with this!

Regards

John Baker
Nov 12 '05 #1
51 5017

On Wed, 12 Nov 2003 16:04:12 GMT, John Baker <Ba******@Verizon.net>
wrote in comp.databases.ms-access:
Some time ago I developed a program in Access, and separated the database and the program
itself (using the normal access tools).We have the db on our server and the programin the
desktop system.
Good for you.
I have modified the program a number of times, and now find that I need
to change the DB slightlt.
This is not at all unusual.
This appears to require that I REMERGE the data base and
program, and I have no idea how to do that.
No - it requires no such thing.
Can someone give me some pointers, since the help package is of NO help with this!


The 'help package' has no help on this because there is no good reason
for such a thing to be required. Why exactly do you believe you must
remerge the files, losing the benefits of separate fe/be deployment,
and going against the good advice of developers and Msft to split
application and data files - good advice that you have already
followed?
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
Nov 12 '05 #2
John,
Why would you need to re-merge the program? I can't think of any reason why
you would need to.

The straightforward way to do it though would be to clear all the linked
tables in the front end and then import the tables from the back end.

Terry
"John Baker" <Ba******@Verizon.net> wrote in message
news:0e********************************@4ax.com...
Hi:

Some time ago I developed a program in Access, and separated the database and the program itself (using the normal access tools).We have the db on our server and the programin the desktop system. I have modified the program a number of times, and now find that I need to change the DB slightlt. This appears to require that I REMERGE the data base and program, and I have no idea how to do that.

Can someone give me some pointers, since the help package is of NO help with this!
Regards

John Baker

Nov 12 '05 #3
John,
I think what your saying is that you split the database into a Front end
(forms, queries, reports) and a Back end (tables) and now want to return the
tables to the current back end.

Make a Back Up copy of the Back end first.

Open the Front end database (with the Forms, Queries, etc.).
Delete the linked tables (the linked tables will have an arrow next to them
showing they are linked). If there is no arrow, then that table resides on
the Front end and should NOT be deleted.
Don't worry, you are not deleting the tables in the Back end, just the links
between the Front and Back ends.

Once the linked tables are deleted, click File + Get External Data + Import
Follow the wizard and import the tables definition and data, and
relationships, from the Back end.

That should be all you need.
Make sure the relationships are correct.

The former Back end still contains the original tables and data.
The former Front end now contains everything and is no longer linked to the
old Back end.
--
Fred

Please reply only to this newsgroup.
I do not reply to personal e-mail.
"John Baker" <Ba******@Verizon.net> wrote in message
news:0e********************************@4ax.com...
Hi:

Some time ago I developed a program in Access, and separated the database and the program itself (using the normal access tools).We have the db on our server and the programin the desktop system. I have modified the program a number of times, and now find that I need to change the DB slightlt. This appears to require that I REMERGE the data base and program, and I have no idea how to do that.

Can someone give me some pointers, since the help package is of NO help with this!
Regards

John Baker

Nov 12 '05 #4
Terry,

How would you clear all the linked tables in the front end and then import the
tables from the back end with code?

Thanks!

Heather
"Terry Kreft" <te*********@mps.co.uk> wrote in message
news:bo**********@newsreaderg1.core.theplanet.net. ..
John,
Why would you need to re-merge the program? I can't think of any reason why
you would need to.

The straightforward way to do it though would be to clear all the linked
tables in the front end and then import the tables from the back end.

Terry
"John Baker" <Ba******@Verizon.net> wrote in message
news:0e********************************@4ax.com...
Hi:

Some time ago I developed a program in Access, and separated the database

and the program
itself (using the normal access tools).We have the db on our server and

the programin the
desktop system. I have modified the program a number of times, and now

find that I need
to change the DB slightlt. This appears to require that I REMERGE the data

base and
program, and I have no idea how to do that.

Can someone give me some pointers, since the help package is of NO help

with this!

Regards

John Baker


Nov 12 '05 #5
Fred,

How would you do all you say with code?

Thanks!

Heather
"Fredg" <fg******@example.invalid> wrote in message
news:dP***********************@bgtnsc04-news.ops.worldnet.att.net...
John,
I think what your saying is that you split the database into a Front end
(forms, queries, reports) and a Back end (tables) and now want to return the
tables to the current back end.

Make a Back Up copy of the Back end first.

Open the Front end database (with the Forms, Queries, etc.).
Delete the linked tables (the linked tables will have an arrow next to them
showing they are linked). If there is no arrow, then that table resides on
the Front end and should NOT be deleted.
Don't worry, you are not deleting the tables in the Back end, just the links
between the Front and Back ends.

Once the linked tables are deleted, click File + Get External Data + Import
Follow the wizard and import the tables definition and data, and
relationships, from the Back end.

That should be all you need.
Make sure the relationships are correct.

The former Back end still contains the original tables and data.
The former Front end now contains everything and is no longer linked to the
old Back end.
--
Fred

Please reply only to this newsgroup.
I do not reply to personal e-mail.
"John Baker" <Ba******@Verizon.net> wrote in message
news:0e********************************@4ax.com...
Hi:

Some time ago I developed a program in Access, and separated the database

and the program
itself (using the normal access tools).We have the db on our server and

the programin the
desktop system. I have modified the program a number of times, and now

find that I need
to change the DB slightlt. This appears to require that I REMERGE the data

base and
program, and I have no idea how to do that.

Can someone give me some pointers, since the help package is of NO help

with this!

Regards

John Baker


Nov 12 '05 #6
Peter:

The response I get when I try and open the Tables in design mode implies that I cant
change all the characteristic of the db through design mode when I am working with a
linked table. I assumed I had to recombine somehow to change the db itself.

The way this has worked is that I have a copy of the db and the program files (seperated)
on my system at home, and use that for development etc. When updates are required for the
programs, I make the changes on my home system, copy the programs section (only) into a cd
and then copy it into the local systems at work. I then change the linkage to point to the
server db and we are off and running.

I gather this is the correct thing to do!

Regards

John Baker

Peter Miller <pm*****@pksolutions.com> wrote:

On Wed, 12 Nov 2003 16:04:12 GMT, John Baker <Ba******@Verizon.net>
wrote in comp.databases.ms-access:
Some time ago I developed a program in Access, and separated the database and the program
itself (using the normal access tools).We have the db on our server and the programin the
desktop system.


Good for you.
I have modified the program a number of times, and now find that I need
to change the DB slightlt.


This is not at all unusual.
This appears to require that I REMERGE the data base and
program, and I have no idea how to do that.


No - it requires no such thing.
Can someone give me some pointers, since the help package is of NO help with this!


The 'help package' has no help on this because there is no good reason
for such a thing to be required. Why exactly do you believe you must
remerge the files, losing the benefits of separate fe/be deployment,
and going against the good advice of developers and Msft to split
application and data files - good advice that you have already
followed?
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


Nov 12 '05 #7
Heather,
Why would you want to take the time to write and debug the code, when doing
it manually would take less than 5 minutes?

If you still want to bother, search
http://www.groups.google.com

for back posts on this.

--
Fred

Please reply only to this newsgroup.
I do not reply to personal e-mail.
"Heather" <ha******@cseducationalsystems.org> wrote in message
news:pV*******************@newsread2.news.atl.eart hlink.net...
Fred,

How would you do all you say with code?

Thanks!

Heather

** snipped **
Nov 12 '05 #8
Open the backend database and change the table structure. The changes will
be reflected in the front end links.

Close all front ends 1st.

"John Baker" <Ba******@Verizon.net> wrote in message
news:po********************************@4ax.com...
Peter:

The response I get when I try and open the Tables in design mode implies that I cant change all the characteristic of the db through design mode when I am working with a linked table. I assumed I had to recombine somehow to change the db itself.
The way this has worked is that I have a copy of the db and the program files (seperated) on my system at home, and use that for development etc. When updates are required for the programs, I make the changes on my home system, copy the programs section (only) into a cd and then copy it into the local systems at work. I then change the linkage to point to the server db and we are off and running.

I gather this is the correct thing to do!

Regards

John Baker

Peter Miller <pm*****@pksolutions.com> wrote:

On Wed, 12 Nov 2003 16:04:12 GMT, John Baker <Ba******@Verizon.net>
wrote in comp.databases.ms-access:
Some time ago I developed a program in Access, and separated the database and the programitself (using the normal access tools).We have the db on our server and the programin thedesktop system.


Good for you.
I have modified the program a number of times, and now find that I need
to change the DB slightlt.


This is not at all unusual.
This appears to require that I REMERGE the data base and
program, and I have no idea how to do that.


No - it requires no such thing.
Can someone give me some pointers, since the help package is of NO help
with this!
The 'help package' has no help on this because there is no good reason
for such a thing to be required. Why exactly do you believe you must
remerge the files, losing the benefits of separate fe/be deployment,
and going against the good advice of developers and Msft to split
application and data files - good advice that you have already
followed?
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

Nov 12 '05 #9
Fred,

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. Via code
I would like to merge the FE and BE and then copy to CD. This makes copying to
CD easier 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.

Heather
"Fredg" <fg******@example.invalid> wrote in message
news:ZA***********************@bgtnsc04-news.ops.worldnet.att.net...
Heather,
Why would you want to take the time to write and debug the code, when doing
it manually would take less than 5 minutes?

If you still want to bother, search
http://www.groups.google.com

for back posts on this.

--
Fred

Please reply only to this newsgroup.
I do not reply to personal e-mail.
"Heather" <ha******@cseducationalsystems.org> wrote in message
news:pV*******************@newsread2.news.atl.eart hlink.net...
Fred,

How would you do all you say with code?

Thanks!

Heather

** snipped **

Nov 12 '05 #10
"paii, Ron" <pa**@packairinc.com> wrote in message
news:vr***********@corp.supernews.com...
Open the backend database and change the table structure. The changes will be reflected in the front end links.


Not until you refresh the links though.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 12 '05 #11
ha******@cseducationalsystems.org (Heather) wrote in
<eX*******************@newsread2.news.atl.earthlin k.net>:
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. Via code I would like to merge the FE and BE
and then copy to CD. This makes copying to CD easier 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.


Ok, now, the following is little more than air code (written in
Access, but not tested). It gives you the basic structure you need,
though it's probably got some problems in it:

Public Sub DeleteLinkedTables()
Dim db As Database
Dim tdf As TableDef

Set db = CurrentDb()
For Each tdf In db.TableDefs
If Len(tdf.Connect & vbNullString) <> 0 Then
db.TableDefs.Delete (tdf.Name)
End If
Next tdf

Set tdf = Nothing
Set db = Nothing
End Sub

Public Sub ImportTables(strDB As String)
Dim db As Database
Dim tdf As TableDef
Dim strTable As String

Set db = DBEngine.OpenDatabase(strDB)
For Each tdf In db.TableDefs
If Len(tdf.Connect & vbNullString) <> 0 Then
strTable = tdf.Name
DoCmd.TransferDatabase acImport, , strDB, acTable,
strTable, strTable
End If
Next tdf

Set tdf = Nothing
db.Close
Set db = Nothing
End Sub

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #12

On Wed, 12 Nov 2003 17:53:44 GMT, John Baker <Ba******@Verizon.net>
wrote in comp.databases.ms-access:
The response I get when I try and open the Tables in design mode implies that I cant
change all the characteristic of the db through design mode when I am working with a
linked table.
That is correct. If you want to change table characteristics, you
need to do this on the tables - not on the links. As Ron indicated in
his follow-up, make table changes to the backend, and code/visual
design changes to the front-end. Relink the tables in the FE once the
BE table changes are made.
I assumed I had to recombine somehow to change the db itself.
No. Not at all. Not only is that way more work than necessary, but
it is counterproductive. Leave the files split and just make the
table changes in the second file, where they belong.
The way this has worked is that I have a copy of the db and the program files (seperated)
on my system at home, and use that for development etc. When updates are required for the
programs, I make the changes on my home system, copy the programs section (only) into a cd
and then copy it into the local systems at work. I then change the linkage to point to the
server db and we are off and running.

I gather this is the correct thing to do!


Yes, but you'll also want to make the backend changes to the data file
at work too. If the db is not in use when you're away from the
office, you could just copy your modified backend (along with
frontend) back onto the work systems, but if the file IS in use at
work while you're away, then you will want to make the backend mods
directly to the backend when back at work rather than overwriting the
backend.
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
Nov 12 '05 #13
Thank You!

Heather
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.86.. .
ha******@cseducationalsystems.org (Heather) wrote in
<eX*******************@newsread2.news.atl.earthlin k.net>:
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. Via code I would like to merge the FE and BE
and then copy to CD. This makes copying to CD easier 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.


Ok, now, the following is little more than air code (written in
Access, but not tested). It gives you the basic structure you need,
though it's probably got some problems in it:

Public Sub DeleteLinkedTables()
Dim db As Database
Dim tdf As TableDef

Set db = CurrentDb()
For Each tdf In db.TableDefs
If Len(tdf.Connect & vbNullString) <> 0 Then
db.TableDefs.Delete (tdf.Name)
End If
Next tdf

Set tdf = Nothing
Set db = Nothing
End Sub

Public Sub ImportTables(strDB As String)
Dim db As Database
Dim tdf As TableDef
Dim strTable As String

Set db = DBEngine.OpenDatabase(strDB)
For Each tdf In db.TableDefs
If Len(tdf.Connect & vbNullString) <> 0 Then
strTable = tdf.Name
DoCmd.TransferDatabase acImport, , strDB, acTable,
strTable, strTable
End If
Next tdf

Set tdf = Nothing
db.Close
Set db = Nothing
End Sub

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

Nov 12 '05 #14
On Wed, 12 Nov 2003 12:54:21 -0600, "Rick Brandt"
<ri*********@hotmail.com> wrote in comp.databases.ms-access:
Not until you refresh the links though.


Absolutely. Corruption can occur if a fe with old links is used to
access data with modified structures. It won't always occur, but it
*can* and *does* occur at times. Refreshing links when table
definitions change is VERY important.

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
Nov 12 '05 #15

Heather,

On Wed, 12 Nov 2003 18:26:18 GMT, "Heather"
<ha******@cseducationalsystems.org> wrote in comp.databases.ms-access:
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.
Not an unusual situation.
Via code
I would like to merge the FE and BE and then copy to CD. This makes copying to
CD easier
...because two files are a LOT harder to write to cd than one? Please.
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.


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
Nov 12 '05 #16
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" <pm*****@pksolutions.com> wrote in message
news:cf********************************@4ax.com...

Heather,

On Wed, 12 Nov 2003 18:26:18 GMT, "Heather"
<ha******@cseducationalsystems.org> wrote in comp.databases.ms-access:
I have a central split database maintained by two admins. I'm going to need toneed to send a copy of the database to six remote sites monthly on CD.


Not an unusual situation.
Via code
I would like to merge the FE and BE and then copy to CD. This makes copying toCD easier


..because two files are a LOT harder to write to cd than one? Please.
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.


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

Nov 12 '05 #17


Heather,

On Wed, 12 Nov 2003 20:44:16 GMT, "Heather"
<ha******@cseducationalsystems.org> wrote in comp.databases.ms-access:
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?


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
Nov 12 '05 #18
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
Nov 12 '05 #19
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" <pm*****@pksolutions.com> wrote in message
news:2b********************************@4ax.com...


Heather,

On Wed, 12 Nov 2003 20:44:16 GMT, "Heather"
<ha******@cseducationalsystems.org> wrote in comp.databases.ms-access:
Are you recommending just to copy both files(FE and BE) to a CD and distributeto each remote location? Why would the links need refreshed if done this way?


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

Nov 12 '05 #20

Heather,

On Wed, 12 Nov 2003 22:39:45 GMT, "Heather"
<ha******@cseducationalsystems.org> wrote in comp.databases.ms-access:
Thank you for staying with me!
No problem.
How does refreshing know where the BE is at?
Refreshing doesn't. If its done manually, it would involve simply
opening the file, go to Tools/DatabaseUtilities/LinkedTableMAnager and
then enabling 'always prompt for new location', choosing 'select all'
and then pointing to the be in the current directory.
Could you share some code to have the fe's links refreshed to point
to the be, at whatever its new location.


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.mdb"
for each t in currentdb.tabledefs
if t.connect<>"" then
t.connect=";database=" & 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
Nov 12 '05 #21
Thanks, Peter, you have helped me a lot. I appreciate it.

Heather
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:6o********************************@4ax.com...

Heather,

On Wed, 12 Nov 2003 22:39:45 GMT, "Heather"
<ha******@cseducationalsystems.org> wrote in comp.databases.ms-access:
Thank you for staying with me!


No problem.
How does refreshing know where the BE is at?


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


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.mdb"
for each t in currentdb.tabledefs
if t.connect<>"" then
t.connect=";database=" & 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

Nov 12 '05 #22
pm*****@pksolutions.com (Peter Miller) wrote in
<cf********************************@4ax.com>:
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.


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
Nov 12 '05 #23
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 programmatically 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" <Ba******@Verizon.net> wrote in message
news:mj********************************@4ax.com...
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
Nov 12 '05 #24

Tom,

On Wed, 12 Nov 2003 22:40:56 -0800, "Tom Wickerath"
<AO***********************@comcast.net> wrote in
comp.databases.ms-access:
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?


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
Nov 12 '05 #25
> 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.
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.
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.
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.
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.
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" <pm*****@pksolutions.com> wrote in message
news:er********************************@4ax.com...

Tom,

On Wed, 12 Nov 2003 22:40:56 -0800, "Tom Wickerath"
<AO***********************@comcast.net> wrote in
comp.databases.ms-access:
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?

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
Nov 12 '05 #26
"Tom Wickerath" <AO***********************@comcast.net> wrote in
news:Ec********************@comcast.com:
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 programmatically 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.


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)
Nov 12 '05 #27
.... 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" <AO***********************@comcast.net> wrote in message
news:Ar********************@comcast.com...
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.
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.
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.
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.
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.
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" <pm*****@pksolutions.com> wrote in message
news:er********************************@4ax.com...

Tom,

On Wed, 12 Nov 2003 22:40:56 -0800, "Tom Wickerath"
<AO***********************@comcast.net> wrote in
comp.databases.ms-access:
Peter: I guess a good question for you is why are you so adamant that this is notsomething that one might want to do, given that a rather talented developer in thedatabase field as smart and skilled as Scott Barker has chosen to do just
this very 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

Nov 12 '05 #28
Lyle,

I think you meant ... (go to bottom)
"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Tom Wickerath" <AO***********************@comcast.net> wrote in
news:Ec********************@comcast.com:
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 programmatically 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.


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)


.... and the above is nonsense <g>.
Terry
Nov 12 '05 #29

Tom,

On Thu, 13 Nov 2003 02:07:43 -0800, "Tom Wickerath"
<AO***********************@comcast.net> wrote in
comp.databases.ms-access:
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.
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.


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'?
You are the one who jumped
to the conclusion that this was an "ill-conceived idea",
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.
suggested that David might be "toying" with Heather by offering some code,
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.
and implied that someone is "headed down the wrong path".
It's not just an implication. I'll say it emphatically. Heather
*was* heading down the wrong path.
It seems to me like you're strongly suggesting that everyone blindly agree
with your opinion without dissent.
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?
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.


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


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.


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
Nov 12 '05 #30
pm*****@pksolutions.com (Peter Miller) wrote in
<er********************************@4ax.com>:
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.


Well, if there's more than one user, it's clear that the app should
remain split.

If there's not, then I see no reason not to unsplit it in order to
make the "installation" for the end users easier. Now, there's one
way to split that is transparent to the user, and that's to keep
the front end and back end in the same folder, and have your code
change the connect strings accordingly. Given the choice is a
single MDB or two MDBs stored in the same location, the split
option with auto-update of links seems the best option.

But I can't see that there's anything at all about it that is
superior to sending a single MDB. Heather needs code one way or
other other. Actually, I can see one thing that's superior about an
unsplit database: nothing can go wrong with the linking process at
the client. In other words, less likelihood of a support issue.

As long as it's a single user, I think it's just fine to have an
unsplit db, though I've never created on myself.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #31
AO***********************@comcast.net (Tom Wickerath) wrote in
<Ar********************@comcast.com>:
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.


I'm not sure why he'd need such a thing. My Reconnect code makes
this a piece of cake, even with multiple back ends:

http://www.bway.net/~dfassoc/downloa...Reconnect.html

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #32
pm*****@pksolutions.com (Peter Miller) wrote in
<tg********************************@4ax.com>:
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.


On the contrary. It all depends on how smart the target users are
and whether there's an installation program or not.

If they are novices and are just copying from a CD, copying one
file is less likely to lead to problems than copying two files. The
difference is completely trivial to you and me, yes, but it's not
for people who aren't comfortable managing and copying files.

And there are vastly more people in that situation than I'd like to
admit.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #33

On Thu, 13 Nov 2003 17:16:32 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
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.


On the contrary. It all depends on how smart the target users are
and whether there's an installation program or not.

If they are novices and are just copying from a CD, copying one
file is less likely to lead to problems than copying two files. The
difference is completely trivial to you and me, yes, but it's not
for people who aren't comfortable managing and copying files.

And there are vastly more people in that situation than I'd like to
admit.


<chuckle>

OK, we'll I don't disagree.

But people who would be ok copying one file but have problems copying
two are, no doubt, going to trip up on copying just one file from the
cd too, because they'll need to unset the read-only flag anyway, and
if they can't copy two files to a common folder, they're definitely
not going to be able to make the files read-write without a support
call...
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
Nov 12 '05 #34

On Thu, 13 Nov 2003 17:12:05 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
Well, if there's more than one user, it's clear that the app should
remain split.
<snip>
As long as it's a single user, I think it's just fine to have an
unsplit db, though I've never created on myself.


But, of course, if a fe/be pair is used instead of a single file, the
person sending out the app doesn't need to concern themselves with the
number of users at each remote site.

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
Nov 12 '05 #35
pm*****@pksolutions.com (Peter Miller) wrote in
<tg********************************@4ax.com>:
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. . . .
In the exact circumstances that Heather described, and with novice
users and data that doesn't need to be retained, I'd contemplate
exactly what she was doing. Indeed, I'm not sure I'd split at all.

Now, it could be that this is a situation where the
application/data she's working on is a live application with
multiple users, so it must be split, and she's distributing that to
affiliates of her office who need the data/application, but don't
update it themselves. In that case, with novice users and no
installation program to guarantee that all the needed files get in
the right location, I'd again contemplate what Heather asked about.
. . . 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.


You will note that I didn't answer the original question. I only
answered after Heather described the situation sufficiently for me
to understand that she was asking a reasonable question.

Also, seeing code that solves the single problem could also help
teach Heather and others reading how to work with the TableDefs
collections. Indeed, perhaps someone who has no need for code to
accomplish this specific task learned something by looking at my
air code that will help them accomplish something else.

I just don't see why you're getting bent out of shape on this one,
Peter. We don't actually know enough details about Heather's
situation to know for certain if the key point (multi-user or not)
makes the unsplit database untenable. We also don't know the skill
level of the users she's sending it to, so we can't say for certain
how much benefit there is to having a single file instead of two.

If it's multi-user, then I agree that it makes no sense whatsoever
to unsplit (though if it's read-only data that's being replaced on
a regular basis, then I'm not certain it matters too much; even
though there's little likelihood of data corruption, I'd still
split, just to avoid corruption in the Access project).

If the users are competent with file copying operations and there's
no installation program, then I don't see any reason to unsplit. On
the other hand, even competent users can make a mistake and the
back end could end up in the wrong place, resulting in a support
call, so I can see unsplitting even in those cases.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #36
> 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........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'?
I guess you're right. I was comparing "person a to person b", as a part of my response
SIMPLY BECAUSE I thought your original answers were a bit on the vile side. Instead of
just saying that you didn't agree with this idea and leaving it at that, you used terms
like "ill-conceived idea", and suggested that David might be "toying with Heather by
offering some code", etc. Pretty strong language.

You say "I meant no offense by that remark." As I read it, your comment towards David
sounds plenty offensive to me!
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?
In the case of the person whom I was helping, who had inquired about this idea, it made
more sense because her DB was linked to 4 or 5 separate BE databases, saved on different
servers (\\Server1\Share1, \\Server2,Share2, etc.). She was not the "owner" of each set of
data, so she had no authority to try bringing it all together into a single BE. I realize
that this probably doesn't represent Heather's situation. I didn't pursue Scott's
solution any further since, as written, it only handled a single BE database. I wasn't
attempting to evaluate the finer points of Heather's unique situation. I simply felt that
others should know about an alternative that is available. Let them make up their own
minds. Perhaps there are reasons that neither of us have thought about where it is
beneficial to do this. Like I said, I don't have a copy of this book, so I don't have any
background material to refer to as to the reason why Scott developed this code. I'm sure
one could find his reasons if they had a copy of the book to read.
Its funny that you use 'fair and balanced' in quotes here...

????? It's not my original term, so that's why I enclosed it in quotes. I'm not going to
stoop to a childish level by offering an opinion as to a broadcaster's mindset.

Peter, as far as I'm concerned, this thread is over. I'm not going to waste any more of
my time replying. End of conversation.
Nov 12 '05 #37
pm*****@pksolutions.com (Peter Miller) wrote in
<tg********************************@4ax.com>:
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.
I've already explained in other replies why exactly I think there
is a scenario where it's justified. These include:

1. single user

2. discardable data

3a. novice users with no installation program

3b. any level of user with no installation program

The reasons for this are:

1. ease of installation

2. reduction in support calls because of errors in the file copying
process (i.e., missing one of the files or putting one of them in
the wrong location).

I'm not sure why the app is split in the first place, though,
except that maybe the creation of the data that is being pushed out
to these read-only users is done by a group of people.

Another thing that I just realized from reading Heather's
description is that the MDB may be run directly from the CD. In
that case, you *can't* update the connect strings, so it *must* be
unsplit.
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.


You choose your solutions based on your assessment of the
requirements. In this case, I think the requirements make the
unsplit back end a plausible solution.

However, we don't actually know if Heather's circumstances meet all
the requirements I've outlined. But I was getting frustrated that
people were ignoring her question entirely.

As you know, Peter, it is very common for me to question the
premises behind a question posted in this newsgroup and say that
there is a fundamental problem with the basic approach. In this
case, I thought the circumstances made the choice plausible and
felt that it was useful to post the code.

As it turns out, parallel to my posting the code to do what Heather
asked, you started a discussion with her about relinking. Seems to
me she's learned both bits and all is right with the world.

Why are you in such a snit about it?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #38
"Terry Kreft" <te*********@mps.co.uk> wrote in news:bp03as$gg1$1
@newsreaderm1.core.theplanet.net:
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)


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


Terry

Yes, you're right.

I started to write a response which said something like

.... using the writings of an Access authority to counter Kreft and Miller
is like
using the writings of the Pope to counter Christ and the Holy Ghost.

but my usual sense of discretion prompted me to write something gentler.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #39
To Everyone in the thread ---

Wow!!! What great thought processes going on here. IMO this is the best thread
to ever appear in CDMA. I hope that everyone who follws this newsgroup reads
this thread and learns from the example here how to analyze a situation before
developing a solution. Thanks to everyone who contributed to this thread.

My central database is multiuser and therefore appropriately split. There is
only one BE and the FE has no tables of its own other than the linked tables.
All data input to the database is done at the central database. The database
contains forms to display specific data and reports for hardcopy of specific
data. Users of the central database enter data, call up data on their screens
and printout reports. It is anticipated that over time revisions may be made to
both the FE and BE of the central database.

The use of the database is now going to be extended to six remote sites. The
remote sites will be single user desktops. Because of the nature of the remote
sites, they will never become multi-user. The remote sites will not enter data.
They will only use the database to call up data on their screens and printout
reports using the same forms and reports as the users of the central database.
I'm still looking for a way to block out the data entry part of the database to
the remote sites and thus my question in another thread regarding using the Tag
property of controls in the custom menu and making selected controls not
visible.

The remote sites will be sent a copy of the central database once per month on a
CD. Installation at the remote sites is a definite issue in that the users at
the sites are computer illiterate and lucky to know where the ON/Off switch is
on their computer. Thus installation needs to be as easy as possible. Training
will be given on how to call up the forms and print the reports and it is our
opinion that the users will have no trouble with this because it is data they
are familiar with and work with on a daily basis. The remote sites need to
receive a copy of the FE as well as the BE each month to account for the fact
that revisions may occur to the FE.

Thanks again to all who have been contributing to this thread!!!!!!!!!

Heather
"Heather" <ha******@cseducationalsystems.org> wrote in message
news:eX*******************@newsread2.news.atl.eart hlink.net...
Fred,

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. Via code I would like to merge the FE and BE and then copy to CD. This makes copying to
CD easier 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.

Heather
"Fredg" <fg******@example.invalid> wrote in message
news:ZA***********************@bgtnsc04-news.ops.worldnet.att.net...
Heather,
Why would you want to take the time to write and debug the code, when doing
it manually would take less than 5 minutes?

If you still want to bother, search
http://www.groups.google.com

for back posts on this.

--
Fred

Please reply only to this newsgroup.
I do not reply to personal e-mail.
"Heather" <ha******@cseducationalsystems.org> wrote in message
news:pV*******************@newsread2.news.atl.eart hlink.net...
Fred,

How would you do all you say with code?

Thanks!

Heather

** snipped **


Nov 12 '05 #40

Tom,

On Thu, 13 Nov 2003 09:38:59 -0800, "Tom Wickerath"
<AO***********************@comcast.net> wrote in
comp.databases.ms-access:
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?
In the case of the person whom I was helping, who had inquired about this idea, it made
more sense because her DB was linked to 4 or 5 separate BE databases, saved on different
servers (\\Server1\Share1, \\Server2,Share2, etc.). She was not the "owner" of each set of
data, so she had no authority to try bringing it all together into a single BE.


So this person has 4 or 5 backends on different servers, but no
'authority' whatever that means, to 'merge' the data into a single
backed. I would point out that I wasn't ever suggesting merging
anything - FE's or BE's. My entire point was that no merging is
required. In your user's case, I presume she had the right to read
these 4 or 5 files (obviously) so unless they were packed with data
she *wasn't* linking to in her FE, I would have suggested that she
grab the 4 or 5 backends, along with her FE, and do NO MERGING
WHATSOEVER. By simply relinking to the original backend's, not only
is the whole process faster, but changes to the table structures are
easily made, and if necessary (and in Heather's case, this wasn't, but
in John Baker's case, it was), brought back to the original site.
I realize that this probably doesn't represent Heather's situation.
No, but it is similar to somewhat similar to John's, and he was the
original poster.
Peter, as far as I'm concerned, this thread is over. I'm not going to waste any more of
my time replying. End of conversation.


I understand that, and to be clear, the only reason I'm posting this
is not to continue the thread (I'm happy to let it drop too) but
because you did what I asked you to do above and provided your
rationale for why one should copy tables. I thought it appropriate to
follow up on that topic alone, and have tried to point out that again
the problem was misunderstood. Not only is merging a BE into a FE not
necessary or desirable, but merging multiple BEs into a single BE, as
you suggest as being relevant above, is likewise totally unnecessary.
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
Nov 12 '05 #41


David,

On Thu, 13 Nov 2003 17:41:41 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
The reasons for this are:

1. ease of installation

2. reduction in support calls because of errors in the file copying
process (i.e., missing one of the files or putting one of them in
the wrong location).
While I think these are minor issues, I see your point.
I'm not sure why the app is split in the first place, though,
except that maybe the creation of the data that is being pushed out
to these read-only users is done by a group of people.
Heather confirmed this to be so, but I just assumed that a fe/be split
was done because it was warranted. There are plenty of people who
don't split mdbs when they should, but I don't think I've ever run
into a case where someone did split an mdb when they shouldn't. I
thought it safe to assume that Heather's split app was split for good
reason.
Another thing that I just realized from reading Heather's
description is that the MDB may be run directly from the CD. In
that case, you *can't* update the connect strings, so it *must* be
unsplit.
That is exactly my thinking too. Why not just run the app from a
single mdb on the cd. It'll be a little slower, but saves even the
copy process, and ensures no data entry. I'd also recommend
locking/disabling controls rather than hiding them. Either way they
are rendered unusable, but leaving them visible provides better visual
feedback as to what the app does, and avoids confusion that can be
caused by the apparently strangely laid out remaining controls, and
the lack of certain key aspects.
You choose your solutions based on your assessment of the
requirements. In this case, I think the requirements make the
unsplit back end a plausible solution.

However, we don't actually know if Heather's circumstances meet all
the requirements I've outlined. But I was getting frustrated that
people were ignoring her question entirely.
Well, now that she's posted further, it appears that many of your
assumptions were correct.
As you know, Peter, it is very common for me to question the
premises behind a question posted in this newsgroup and say that
there is a fundamental problem with the basic approach.
Precisely! Which is why your initial response surprised me.
In this
case, I thought the circumstances made the choice plausible and
felt that it was useful to post the code.

As it turns out, parallel to my posting the code to do what Heather
asked, you started a discussion with her about relinking. Seems to
me she's learned both bits and all is right with the world.
Agreed.
Why are you in such a snit about it?


I guess we just saw (and see) it differently. I think a fe/be split
is a very important aspect of good application design, and like most
good application design aspects, serves a wider range of cases better
than more limited designs (like in this case, a single file approach).
I saw the arguments against a fe/be split as being trivial (ie, harder
to copy two files than one), and that it would take more time to
execute a single file solution than the current fe/be one. So I saw a
move away from a good general design principle being made for weak
reasons and requiring extra work. What isn't there about that
combination to raise one's hackles?

That said, with further clarification from Heather, I don't see a
problem with the single-file approach in this limited scenario,
especially if the app is to be run from cd.
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
Nov 12 '05 #42
LOL!

Terry

"Lyle Fairfield" <Mi************@Invalid.Com> wrote in message
news:Xn*******************@130.133.1.4...
"Terry Kreft" <te*********@mps.co.uk> wrote in news:bp03as$gg1$1
@newsreaderm1.core.theplanet.net:
<SNIP>
but my usual sense of discretion prompted me to write something gentler.

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

Nov 12 '05 #43
pm*****@pksolutions.com (Peter Miller) wrote in
<7n********************************@4ax.com>:
On Thu, 13 Nov 2003 17:12:05 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
Well, if there's more than one user, it's clear that the app
should remain split.

<snip>

As long as it's a single user, I think it's just fine to have an
unsplit db, though I've never created on myself.


But, of course, if a fe/be pair is used instead of a single file,
the person sending out the app doesn't need to concern themselves
with the number of users at each remote site.


But they may be concerned with the issue of ease of use. It's
obviously much easier to copy one file than two.

Also, if it's being run directly from the CD that it is distributed
on, then it has to be a single file, unless the CD drive letter is
guaranteed to be the same as the drive letter used to create the
table links. That would mean you'd have to copy the back end to the
CD, then link to the CD data tables, then copy the front end to the
CD. And, of course, it only works if all the destination PCs have
the same drive letter for the CD.

A single file eliminates that problem entirely.

Now, I don't know exactly what Heather's situation is, but in both
cases I think these are plausible justifications for sending an
unsplit MDB.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #44
pm*****@pksolutions.com (Peter Miller) wrote in
<3f********************************@4ax.com>:

On Thu, 13 Nov 2003 17:16:32 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
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.


On the contrary. It all depends on how smart the target users are
and whether there's an installation program or not.

If they are novices and are just copying from a CD, copying one
file is less likely to lead to problems than copying two files.
The difference is completely trivial to you and me, yes, but it's
not for people who aren't comfortable managing and copying files.

And there are vastly more people in that situation than I'd like
to admit.


<chuckle>

OK, we'll I don't disagree.

But people who would be ok copying one file but have problems
copying two are, no doubt, going to trip up on copying just one
file from the cd too, because they'll need to unset the read-only
flag anyway, and if they can't copy two files to a common folder,
they're definitely not going to be able to make the files
read-write without a support call...


Who said they needed to write to it?

My point here is not to describe Heather's situation, because I
don't know the exact details. But I think this is a plausible
justification for not splitting the back end.

The point is that as long as they get the one file copied, they can
use it, even if read-only (which may be sufficient for Heather's
purposes). Adding a second file means adding a number of additional
scenarios that could go wrong, from failing to copy the second
file, to copying it to a location different from the front end.

And MDB as an email attachment or a download from a web page is
another scenario where a single file is easier than two.

It all depends on your user audience, and only Heather can make
that decision.

I think it's a valid choice given those kinds of possible issues.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #45
pm*****@pksolutions.com (Peter Miller) wrote in
<ik********************************@4ax.com>:
Not only is merging a BE into a FE not
necessary or desirable, but merging multiple BEs into a single BE,
as you suggest as being relevant above, is likewise totally
unnecessary.


Perhaps in the scenarios that have been explicitly discussed, but
that does not mean that there are no such scenarios where it might
be justifiable, as you seem to me to be suggesting.

I would agree that it would be the unusual situation where it was
appropriate and that one should attempt a split architecture first,
but that does not mean that particular circumstances can never
justify a different approach.

It's like with normalization. You try to normalize as much as
possible but in a particular application there may be reasons to
denormalize. I see this as precisely the same situation.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #46
pm*****@pksolutions.com (Peter Miller) wrote in
<g1********************************@4ax.com>:
On Thu, 13 Nov 2003 17:41:41 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:

You choose your solutions based on your assessment of the
requirements. In this case, I think the requirements make the
unsplit back end a plausible solution.

However, we don't actually know if Heather's circumstances meet
all the requirements I've outlined. But I was getting frustrated
that people were ignoring her question entirely.


Well, now that she's posted further, it appears that many of your
assumptions were correct.


She hasn't posted further, Peter.
As you know, Peter, it is very common for me to question the
premises behind a question posted in this newsgroup and say that
there is a fundamental problem with the basic approach.


Precisely! Which is why your initial response surprised me.
In this
case, I thought the circumstances made the choice plausible and
felt that it was useful to post the code.

As it turns out, parallel to my posting the code to do what
Heather asked, you started a discussion with her about relinking.
Seems to me she's learned both bits and all is right with the
world.


Agreed.
Why are you in such a snit about it?


I guess we just saw (and see) it differently. I think a fe/be
split is a very important aspect of good application design, and
like most good application design aspects, serves a wider range of
cases better than more limited designs (like in this case, a
single file approach). I saw the arguments against a fe/be split
as being trivial (ie, harder to copy two files than one), and that
it would take more time to execute a single file solution than the
current fe/be one. So I saw a move away from a good general
design principle being made for weak reasons and requiring extra
work. What isn't there about that combination to raise one's
hackles?

That said, with further clarification from Heather, I don't see a
problem with the single-file approach in this limited scenario,
especially if the app is to be run from cd.


Er, the clarification that talked about the CD was, in fact, in the
message to which I replied with the air code to do the job of
unsplitting. And it was the same message that you replied to
explaining about having code for reconnecting automatically.

There has been no further clarification beyond the information both
of us had available to us at the time we replied in parallel.

But, apparently, *you* didn't read her message carefully, since you
didn't see all these "clarifications" that I did see.

This is why it has seemed to me that you'd gone off for no good
reason, as you now acknowledge that Heather's scenario makes
unsplitting a plausible alternative (though not necessarily the
best solution based on the information we had). In short, it seems
to me that you went off on a tear because of a predisposition that
caused you not to read Heather's message carefully, and therefore
to ignore the information that I accounted for in my reply, which
you criticized as perhaps "toying" with her.

Heather has not posted to this thread since her replies to your
solution and mine, and I have no more information about her
situation than I had when I posted my code, and that you had when
you posted your suggestion. What we do have is discussion of that
incomplete scenario, and my additions to the scenario that you
acknowledge make the unsplitting a reasonable (if not optimal)
alternative.

So, basically, at this point you agree that I was providing an
answer to a reasonable request, and not being whimsical or
malicious. But you had all the information you needed to understand
that at the time you sent your "toying" post.

I'm not offended or anything.

I just think there's a lesson here that we need to read posts more
carefully, and when you see someone like me making a post that you
see as uncharacteristic, you should perhaps consider that I gave it
some thought and chose my answer to fit the question asked.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #47

David,

On Fri, 14 Nov 2003 20:16:02 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:
She hasn't posted further, Peter.
<snip>
Er, the clarification that talked about the CD was, in fact, in the
message to which I replied with the air code to do the job of
unsplitting. And it was the same message that you replied to
explaining about having code for reconnecting automatically.

There has been no further clarification beyond the information both
of us had available to us at the time we replied in parallel.
Not true. Heather posted again yesterday morning, prior to my posts
and many of yours, stating in depth what her actual situation was.
But, apparently, *you* didn't read her message carefully, since you
didn't see all these "clarifications" that I did see.
Before you go off on a rant, check groups.google.com. You're
obviously mistake, and so your conclusions about my misreading things
are obviously off base.
Heather has not posted to this thread since her replies to your
solution and mine, and I have no more information about her
situation than I had when I posted my code, and that you had when
you posted your suggestion. What we do have is discussion of that
incomplete scenario, and my additions to the scenario that you
acknowledge make the unsplitting a reasonable (if not optimal)
alternative.
Why do you insist that Heather never followed up? Not only are you
wrong, but if there was any confusion about who may have seen which
posts, you could easily have verified this by a google search.
So, basically, at this point you agree that I was providing an
answer to a reasonable request, and not being whimsical or
malicious. But you had all the information you needed to understand
that at the time you sent your "toying" post.
Wrong.
I'm not offended or anything.

I just think there's a lesson here that we need to read posts more
carefully, and when you see someone like me making a post that you
see as uncharacteristic, you should perhaps consider that I gave it
some thought and chose my answer to fit the question asked.


<chuckle>

Yes. *We* do.

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
Nov 12 '05 #48
pm*****@pksolutions.com (Peter Miller) wrote in
<rl********************************@4ax.com>:
On Fri, 14 Nov 2003 20:16:02 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote in comp.databases.ms-access:
She hasn't posted further, Peter.


<snip>
Er, the clarification that talked about the CD was, in fact, in
the message to which I replied with the air code to do the job of
unsplitting. And it was the same message that you replied to
explaining about having code for reconnecting automatically.

There has been no further clarification beyond the information
both of us had available to us at the time we replied in
parallel.


Not true. Heather posted again yesterday morning, prior to my
posts and many of yours, stating in depth what her actual
situation was.


OK, I didn't see that post until after I'd replied to you, because
my newsreader sorts threaded by oldest post in a subthread. Her
post stood at the top of a subthread (because the post it was a
reply to had alread been marked as read), so it sorted last.

But it didn't supply anything but confirmation of the suppositions
I had already made based on the information she *did* provide.
But, apparently, *you* didn't read her message carefully, since
you didn't see all these "clarifications" that I did see.


Before you go off on a rant, check groups.google.com. You're
obviously mistake, and so your conclusions about my misreading
things are obviously off base.


You had just as much information as I did before this last post of
Heather's, and you could not conceive of a situation in which
unsplitting was a worthwhile thing to do. Yet, based on the
information Heather had supplied, I was able to construct a
scenario that you agreed was a plausible justification for
unsplitting.
Heather has not posted to this thread since her replies to your
solution and mine, and I have no more information about her
situation than I had when I posted my code, and that you had when
you posted your suggestion. What we do have is discussion of that
incomplete scenario, and my additions to the scenario that you
acknowledge make the unsplitting a reasonable (if not optimal)
alternative.


Why do you insist that Heather never followed up? Not only are
you wrong, but if there was any confusion about who may have seen
which posts, you could easily have verified this by a google
search.


While you're literally correct, her final post did not really
provide anything other than confirmation of the possible scenario I
outlined based on the information she'd originally posted.
So, basically, at this point you agree that I was providing an
answer to a reasonable request, and not being whimsical or
malicious. But you had all the information you needed to
understand that at the time you sent your "toying" post.


Wrong.


Yes, all the information was there, because I figured it out
myself. You're at least as smart as I am, Peter, so there's no
reason why you shouldn't have been able, based on the same
information, to construct a scenario where unsplitting was a
reasonable course of action.
I'm not offended or anything.

I just think there's a lesson here that we need to read posts
more carefully, and when you see someone like me making a post
that you see as uncharacteristic, you should perhaps consider
that I gave it some thought and chose my answer to fit the
question asked.


<chuckle>

Yes. *We* do.


Heather's final post did nothing but confirm the validity of the
scenario I constructed based on the information in her previous
posts.

We had the same information, Peter, from the beginning, yet you
couldn't see any situation that would make unsplitting a plausible
solution. Now you agree that it *is* a valid approach to the
particular problem.

I think you didn't see the possibilities precisely because of a
predisposition to a particular approach to a problem. We all have
such predispositions, but the vehemence of your disagreement with
me that unsplitting was worth contemplating leaves you in something
of an Emily Litella situation -- rather than asking further
questions, you had an unequivocal answer.

I approached the question for what it asked, based on the
information provided.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #49
On Sun, 16 Nov 2003 00:00:10 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote in comp.databases.ms-access:

<snip>
Heather's final post did nothing but confirm the validity of the
scenario I constructed based on the information in her previous
posts.
As you've repeated four times, and I'll take you on your word that
although your scenario exactly matched that which Heather clarified in
her follow-up, that you did not in fact see her post before posting
the many posts where you reference the scenario.
We had the same information, Peter, from the beginning, yet you
couldn't see any situation that would make unsplitting a plausible
solution. Now you agree that it *is* a valid approach to the
particular problem.
Yes.

But remember, just because I say ok, it wouldn't be a mistake to
unsplit given a slew of conditions, doesn't mean I think it should be
done. Personally, I think that if an app is in a well designed state,
it often makes more sense to keep it flexible, than to limit in a way
that may work well for a very specific implementation, but will need
to be reworked if that situation varies even slightly. If any of
Heather remote offices ever needed more active involvement in the
process, her re-merged solution fails quickly and needs to be
reworked. Had she stuck with the original better design, she could
easily handle multiple users at each remote site, the ability for them
to edit data, etc, etc.

So while I agree that the scenario outlined does not make an unmerged
implementation as crazy as it first sounded to me, I'm not in any way
suggesting I would unmerge the files.
I think you didn't see the possibilities precisely because of a
predisposition to a particular approach to a problem. We all have
such predispositions, but the vehemence of your disagreement with
me that unsplitting was worth contemplating leaves you in something
of an Emily Litella situation -- rather than asking further
questions, you had an unequivocal answer.
I'm sorry. I didn't see the post where you asked for further details
before posting a solution. Did I miss it?

I posted that I thought it better to rethink the need than seek the
code because that is what I thought was appropriate. I still think
she is better served by thinking through the issues than pouncing on a
workable piece of code and implementing it.
I approached the question for what it asked, based on the
information provided.


As did I. We just had different views on the suitability of the
requested solution.

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
Nov 12 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Mark Creelman | last post by:
Hello all: I am attempting to use a database program that I downloaded from http://www.thescripts.com/serversidescripting/perl/tutorials/asimpledatabaseprogram/database.txt with good...
0
by: wwwursa | last post by:
I am having a problem entering the very first record in a database program using a DAO control and writing the code in vb6. From what I can ascertain the problem is as follows. I have the...
1
by: terryskorski | last post by:
After reading the tutorial about the Perl Database Program: Perl Database Tut. I was wondering if anyone could help me have it interface with a MySQL database instead of storing information in...
5
by: OBA | last post by:
I am new to vb6, but I was trying to find how can I write a small database program, that can be used by several computers in 1 location (for example: Office), the problem i encounter is that if the...
3
by: mim001 | last post by:
i want t o about example of database program
1
by: HDI | last post by:
Hi, I'm looking for the most user friendly way to develop a database program. Maybe some of you have got some nice experience and ideas that I can use. I always worked with sql statements te...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.