unsplit database (1 Viewer)

rgreene

Registered User.
Local time
Today, 23:50
Joined
Jan 22, 2002
Messages
168
I used the database splitter to split my database but now I need to do some testing on it and I don't want to use the REAL thing. So I copied the database but I'm still linked to the REAL data. How do I "unsplit" or bring everything back into 1 database?

Thanks,
Rick
 
Hello.

You can make a copy of your backend, and put it on your desktop and name it so that you know it's the testing copy.

Then open up the copy of the front end where it shows the database window. Go to tools and select Linked Table Manager. Check the box for prompt for new location and check all the tables listed. then say okay.

It will then promt you to select the new location of the tables to be linked. Click on your backend copy.

I think that should pretty much be it..... Hope that helps.
 
Last edited:
You need to copy both the fe and be to your PC. THEN open the linked tables manager and redirect the fe links to the local copy of the be. Don't forget to re-direct them when you finish your changes.
 
i recently came into the same situation described in this thread. i have a follow up question to this. is there any way to get both the FE and BE into a single application (unsplit)? so basically i'll only have one .MDB file?

thanks for any suggestions everyone.
 
I just ended up copying and pasting all my query's, forms, reports, etc.. into the proper areas in the BE database. Then I renamed it to mdb. Everything seems OK. Not exactly what I wanted to do but it was the only thing I could think of to accomplish what I wanted.
 
yeah i was thinking along the same lines. importing the tables into the FE might also be another option. either way i have to make sure all my ControlSources for forms, queries, and reports are properly set.

thanks for the response rgreene. it was helpful.
 
I don't know why you would want to but the easiest way to get the db back together again is to delete the links to the be tables and then use the file/get external data to import them.
 
Another thing to consider is where the Table relationships are FE or BE. I think they should be in the BE, I've never tried them in the FE, so it might be easer in the long run to import everything to the BE.

Regards
Chris
 
The relationships MUST be defined where the physical tables reside. That is the only place where you can enforce referential integrity. You can import the relationships when you import the tables.
 
After reading, it sounds like once you split a database, the best practice is to create a copy of each for staging and remap them, but in the end, there is no real need to unsplit the fe and be once split, unless you plan on distributing the application that way to begin with. Is that right?
 
I posted the procedure to recombine in #7. I have done it on occasion where I wanted to make a sample a remote user could easily work with for testing. There is no valid reason for having a monolithic application once you deliver it to the users. In all cases single user or multi, local or remote, splitting gives a more stable and upgradeable and more easily testable solution.

In some applications where the client might have a need to relink the BE, I include a form that makes it easy. Sometimes, I use code in the opening form to find the BE if I always want it to be in a specific location.
 
Isn't it easier to right-click on the linked tables and choose to convert it to a local table?

I have done that plenty of times for testing.
 
Once you have a split database, I can see no good reason to re-combine it. There are a few things that work differently in split and non-split databases, which is another reason to be consistent.
 
Ahhhhhhhh, its the thread that won't die.

Talk to you all in October 2020.
 
Once you have a split database, I can see no good reason to re-combine it. There are a few things that work differently in split and non-split databases, which is another reason to be consistent.

The only time I ever do this is to create a working DEMO version of my split databases in order for potential customers to 'try before they buy'.
When I do so, I right click and convert to local table as suggested by psycotic1

EDIT: sorry plog. Didn't read your contribution before posting. It was too recent! ;)
 
Ahhhhhhhh, its the thread that won't die.

Thread necromancy... Latest trend in bringing the dead back!!!

Necromancer-names-main-e1509013319706.png
 
Is that art from the cover or an illustration in some novel?

Or is it perhaps an MTG card about raising the dead from the graveyard to some other specified place?
 
Nope... Google images, grab the first one that looked obviously "Undead" related, and I figured a necromancer dancing with a zombie fit well with tendency for some to bring long dead threads back!
 

Users who are viewing this thread

Back
Top Bottom