Combining a split database ?

D

dhstein

Is there a way to recombine a split database? The idea is to copy the
database to another system over the weekend (home system), make changes, then
put it back Monday morning and split it. It would make changes easier. The
alternative is to simulate the Network drive on my home system which I can do
but the first method would be easier. Thanks for any help on this.
 
K

ken

Its easy enough to do, but I don't see that it offers any advantages.
In fact there are some things which don't work with linked tables
which do with local tables, so you could accidentally find your self
including some functionality at home which won't work back at the
office. I'll deal first with leaving it split, then with
'unsplitting' it:

1. All you need to do is copy the front end file and the back end
file onto your hone system. They can both go in the same folder or in
different folders. Then open the front end and use the built in
Linked Table Manager to refresh the links to the new location of the
back end file on your home system.

When you copy the front end back to the office system you'll need to
use the Linked Table Manager to refresh the links back to the network
location of course, but it only takes a few moments to do this. Or
you can automate the process. Some years ago I did post a means of
doing this by checking for invalid links at start-up for both single
and multiple back ends at:

http://community.netscape.com/n/pfx/forum.aspx?msg=19444.1&nav=messages&webtag=ws-msdevapps

2. To 'unsplit' a database you delete all the linked tables from the
front end; this deletes only the links not the tables in the back
end. Then import all the tables from the back end via the File |Get
External data | Import menu item on the main database menu bar (or the
equivalent in 2007). Or you can automate it with the following
function:

Public Function CopyTables(dbsSource As Database, strSourcedb As
String)

On Error GoTo Err_Handler

Dim dbs As DAO.Database
Dim tdf As DAO.TableDef
Dim fld As DAO.Field, newfld As DAO.Field
Dim rel As DAO.Relation, newrel As DAO.Relation
Dim lngCount As Long, lngN As Long
Dim retVal As Variant

Set dbs = CurrentDb

'loop through tabledefs collection and copy tables
lngCount = dbsSource.TableDefs.Count
retVal = SysCmd(acSysCmdInitMeter, "Copying Tables", lngCount)
lngN = 1
For Each tdf In dbsSource.TableDefs
If Left(tdf.Name, 4) <> "MSys" Then
retVal = SysCmd(acSysCmdUpdateMeter, lngN)
lngN = lngN + 1
DoCmd.TransferDatabase acImport, "Microsoft Access", _
strSourcedb, acTable, tdf.Name, tdf.Name
End If
Next tdf

' rebuild relationships
lngCount = dbsSource.Relations.Count
retVal = SysCmd(acSysCmdInitMeter, "Building Relationships",
lngCount)
lngN = 1
For Each rel In dbsSource.Relations
retVal = SysCmd(acSysCmdUpdateMeter, lngN)
lngN = lngN + 1
' Create new Relation object
Set newrel = dbs.CreateRelation(rel.Name, rel.Table,
rel.ForeignTable)
' Set attributes
newrel.Attributes = rel.Attributes
For Each fld In rel.Fields
' Create field in Relation object.
Set newfld = newrel.CreateField(fld.Name)
' Specify field name in foreign table.
newfld.ForeignName = fld.ForeignName
' Append Field object to Fields collection of Relation
object.
newrel.Fields.Append newfld
Next fld
' Append Relation object to Relations collection.
dbs.Relations.Append newrel
dbs.Relations.Refresh
Next rel

Exit_Here:
' clear status bar
retVal = SysCmd(acSysCmdClearStatus)
Set dbsSource = Nothing
Exit Function

Err_Handler:
MsgBox Err.Description
Resume Exit_Here

End Function

The function is called like so:

Dim dbs As DAO.Database, dbSource As DAO.Database
Dim strSourcedb As String

strSource db = <path to database from which tables to be imported>
Set dbSource = OpenDatabase(strSourcedb)

CopyTables dbSource, strSourcedb

Ken Sheridan
Stafford, England
 
A

Albert D. Kallal

dhstein said:
Is there a way to recombine a split database? The idea is to copy the
database to another system over the weekend (home system), make changes,
then
put it back Monday morning and split it. It would make changes easier.
The
alternative is to simulate the Network drive on my home system which I can
do
but the first method would be easier. Thanks for any help on this.

No need to re-combine. Simply take a copy of the front end, and the back
end,and place them on your computer in some folder. Run the linked table
manager to link the front end to the back end..and you can then develop.

In fact, if you don't change your table structure..you can continue working
during the week and not have to send everyone home while your work. Or, you
don't have to work all weekend..but can happy work on your new updates and
new features all week long. when you ready to deploy you simply when back at
work go:

first, re-link your front end to the production back end

create the mde

then deploy that new mde to each users computer.

So, the whole idea behind a split system is that you can continue to
work..and even work off site. You just have to get used to using the linked
table manger when you do this. Thus, you ONLY have to send people home or
kick them out of the system if your going to make changes to the tables
structure such as adding new tables, or even adding new field to tables. In
this case your make the changes in the real back end, and thus you WILL have
to kick users out when you do this.

However, even in the case in which the back end structure is changed, if it
is something simple like adding a new field to an existing table then you
can actually continue to work off site. You simply open up a word document
and make some notes of what table(s) you changed and the name/type etc of
the field you changed in that table.

When you are ready to deploy you "new" version (say Wednesday after working
all day Mon and Tues on this), you can during lunch have everyone exit the
application. You then simply open up the "production" back end and while
looking at your word document simply add the few new fields you added while
working on new features. Once you don this, then again simple go:

Now, simple re-link your front end to the production back end (that now has
those new changes to the table structure).

Then create the mde

then deploy that new mde to each users computer.


So, there no reason at all to re-combine your application at all. In fact,
you can continue working all day Monday EVEN while users are happy working
away on the real production "live" version of your software.

About the only time I have to kick everyone out for an extended period of
time is when the back table changes are SIGNIFICANT such as adding new
tables and setting up relationships. Even in this case, I still often make
notes in that word doc, and then when I ready to update the production back
end, I actually "copy" in the new tables from my development back end into
the production back end (and then setup relationships). Once again, then I
ready to re-link the front end and re-deploy that to users.

In other words, the split system is the VERY means we use to develop
software without having our users to stop working with the live system....

You can re-combine quite easy, but I really see no reason to. In fact, if
you test dangerous deletion code or other features that updates data, ten
you REALLY don't want to test this on the live data anyway. So, an added
feature of a split system is you can test dangerous code without every
having to touch the "live" production data...
 
D

dhstein

Ken and Albert,

Thanks for your replies. I'll have to "play" with it a little bit to
figure out all the nuances, but you've given me the main idea. The database
is installed for the users as a runtime only version - they don't have
Access. Does this complicate the picture in any way ? Thanks.

David
 
A

Armen Stein

Thanks for your replies. I'll have to "play" with it a little bit to
figure out all the nuances, but you've given me the main idea. The database
is installed for the users as a runtime only version - they don't have
Access. Does this complicate the picture in any way ? Thanks.

It shouldn't matter. The runtime version of Access doesn't affect
splitting an application.

Also, regarding the linked table manager. If you want a more
automated approach to relinking tables, there are lots of free
techniques out there, including our J Street Access Relinker at:
http://www.jstreettech.com/downloads

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
R

Rocket Ron

Perhaps I don't understand quite what you want but, just in case!
I copy my database file to Memory Stick at the end of the day and then
paste it to my PC at home. If I work on it at home, when I have finished I
reverse the process and then paste it back, at work, the following morning.
Hope this is of some use, I am not really too technical.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top