Opening a second database

[JohnLee]

Hi,

I've tried searching this forum, and don't seem to be able to find anything that can help me.

I have two databases, one is the primary database and the other is what I have called the recovery database. What I would like to do is to open up my recovery database from within my primary database and then close the primary database, leaving the recovery database open.

Does anyone know how this can be acheived.

Any assistance would be most appreciated.

John

 

[DJkarl]

Look at the Shell() function.

 

[JohnLee]

Hi,

Thanks for your reply, but that doesn't mean anything to me, what is the Shell() function, what does it do, how is it used, how is code written etc?

My VB knowledge and skills are limited.

John Lee

 

[DCrake]

Simple Software Solutions

You are referring to two databases; Primary and Recovery, are these two both back end databases? In other words you have a front end database (mdb) that has linked tables to either the Primary back end or the recorvery back end.

Answer this question first as this will enable members to grasp the exact nature of your question.

CodeMaster:

 

[KenHigg]

'Open second .mdb
intX = Shell("c:\msaccess.exe c:\myDatabase.mdb")

'Close this .mdb
DoCmd.Quit

fyi: If you type 'shell' into the vba editor, highlight it and hit F1 help will magically appear

 

[JohnLee]

hi Dcrake and KenHigg,

Thanks for both of your replies, I've chosen KenHigg option as it didn't require me to answer the questions you raised DCrake, because I didn't know what you were talking about. Having chosen KenHigg's option and after reading the help on the shell function in conjunction with KenHigg's sample, I made a sligh adjustment to fit my requirements and it worked great. The following is what I finally ended up with, which works great:

'Open ADDLP_New_Y_Recovery Database
intX = Shell("c:\Program Files\Microsoft Office\Office\msaccess.exe y:\ADDLP\ADDLP_New_Y_Recovery.mdb", vbMaximizedFocus)

Thanks for your help guys.

John

 

[DCrake]

Simple Software Solutions

You may not actually read this as you have resolved the issue. However, on the offchange you do, it concerns me that you did not know what I was talking about regarding Front End - Back End applications. If your Access knowledge is that limited I suggest you read more about this subject for future reference.

 

[JohnLee]

Hi thanks for your response,

Perhaps I'm being a bit dense, but for what purpose would I need to read up on backend and frontend databases? If my understanding is right, isn't that something more to do with SQL databases and the like, which run on large networks.

John

 

[DCrake]

Simple Software Solutions

In simple terms if you have a database that can be used by more than one person or the same person from many locations then you need to set up a backend/frontend enviroment. The front end consists of everything EXCEPT your tables. This is usually loated on the users workstation. The backend holds the data tables. This is ideally sat on a central server. Not only does this mean that you can access the data from whatever machine you have the front end on. It also means that your systems administrator can include this in the companies daily backup schedule.

The other main advantage is that, as a developer, you can maintain a copy of the front end application WITHOUT restricting other users from using the current version.

Lets say that you want to make changes to a form/report and the time schedule is two days. If the database was not split no one would be allowed to use the database for two days. If they did then any additions/ updates/ etc would be lost as the data in your development copy would remain static.

I am sure there are many other reasons for this but these are the primary factors.

 

[JohnLee]

Hi,

Thanks for that, because our IT department would not support my application if something went wrong, the approach I have had to take is to have a backup copy of both the Primary and Recovery DB plus a design copy. the backup copies of the Primary and Recovery DB sit in a different drive location. When ever the Primary DB is ran [which is once a day] it exports copies of all the tables to the backup copy in the seperate drive location as stated. The Recovery DB is really purely for my use should some the printers that print the data have a technical fault. This enables me to recover the data without having to run the whole process from the start. The design DB is an exact copy of the Primary DB and this is where any changes to the design or further develpment are conducted. Once these changes/developments have been completed and tested, I then export them to the primary and backup DB's when they are not in use.

I know it's not the best way, but given that my companies IT department want nothing to do with it, for the moment this the best way to deal with it. I am fortunate in that only 4 people use the DB currently, but they don't ever use it at the same time, they take it in turns, so for the time being unless it's get's rolled out further, it's doable.

John

 

[DCrake]

Simple Software Solutions

If the work you are doing on your databases is mission critical and supports the smooth running of the business then I suggest that managment gets involved and instructs your IT dept to access the situation sin die. Its you arse that on the block if things go wrong all because of tempremental IT geeks. Don't get me wrong I'm an MD and an IT Geek at the same time.

David

 

[JohnLee]

Hi,

Unfortunately this is the work world I live in, I've been done the route with senior management and they support the IT department view. It's all quite political and so I won't bore you with the in's and out's of it. The departments [Accounts and Marketing] that it helps are more than pleased with it, so I am grateful for that. The Senior management have chosen not to recognise what I have done, but there's nothing new in that. I do these sort of things because I like to help where I can, but recognition is nice when you can get it.

Cheers.

John