Spliting A Database

ddrew

seasoned user
Local time
Today, 00:46
Joined
Jan 26, 2003
Messages
911
Hi, I wonder if someone can help please. My DB is built and I now want to split it on my machine into two locations on my Desktop (TIR_FE and TIR_BE) I have put the whole thing into TIR_FE ready for spliting. I have decided that only some of the tables need to be split as not all hold common data, so I only want to split the ones with common data. But I dont know how to define where to send them or how to define which ones to send.
 
Hi, I wonder if someone can help please. My DB is built and I now want to split it on my machine into two locations on my Desktop (TIR_FE and TIR_BE) I have put the whole thing into TIR_FE ready for spliting. I have decided that only some of the tables need to be split as not all hold common data, so I only want to split the ones with common data. But I dont know how to define where to send them or how to define which ones to send.

How many Tables are you talking about? If the number is small enough, then converting all of them and copying back the ones that should not be linked might be an option. in a recent project, a similar situation existed, and after all Tables were copied it was determined that 6 or 7 did not belong there and needed to be copied to the FE.

-- Rookie
 
I think the Rookie's suggested approach is the sensible way to go, here. There is no native way to only include some Tables in the Back End. But what kind of data, exactly, is held in these Tables you want in the Front End? Typically, I think, this would only done for utility Tables that hold data relating to how an individual user wants Forms to be displayed, or possibly holding info as to what Records, in a given Forms, where last accessed.

Linq ;0)>
 
I think the Rookie's suggested approach is the sensible way to go, here. There is no native way to only include some Tables in the Back End. But what kind of data, exactly, is held in these Tables you want in the Front End? Typically, I think, this would only done for utility Tables that hold data relating to how an individual user wants Forms to be displayed, or possibly holding info as to what Records, in a given Forms, where last accessed.

Linq ;0)>

I understand the premise of the OPs situation, if not the details. In the database that I used as an example, there were temporary Tables that were used to hold session based information, which could differ from user to user that were built and refreshed in the Front End as they were needed.

-- Rookie
 
First make a copy of your DB and save it somewhere safe. Always a good practice just in case something goes terribly wrong.

Then split your database. You will have your frontend and backend in two different DBs.

Open your frontend and delete the linked tables that you want to hold just session data. Then import from your backend those deleted tables.

That is how I would do it :)
 

Users who are viewing this thread

Back
Top Bottom