Saving form to another database

[nemPyong]

So, I really am a noob to access and have a very very lil knowledge about network...

So, the case is:
I have tables, forms, and (will be) many data. But many data means that the file will be heavy (e.g. need a longer time to open it) and since it's located in server, meant that it'll also burden the servers when someone is accessing it. So, the idea is to make an access file consisted only of forms (and maybe tables), and another access file as the data-bank. And everytime the form is filled, it'll save the new data to the data-bank. So, it will be easier for the end-users to acess the form (e.g. saving time when opening the file).

My question is:
1) Is it really lessening the burden on server?
Because I think that even if the end-user only accessing the form, the form itself will be accessing the bank-data, and I do not see how it'll lessen all the process.
2) How to save to another database?
I used this command on VB:

Set db = CurrentDb

Can it be used to save the form's data to another access database? How?

Even if you only know the answer to one of the question, please let me know
Thank you very much

 

[CJ_London]

That is the way you should be doing it - the part that is in the users machine is called the Front End and the data on the network is called the Back End

1) Is it really lessening the burden on server?

Yes - because the network is not having to manage the form - plus it will make the system easier to maintain.

2) How to save to another database?

This is called splitting the database and is a function available within Access. To do this manually, create a copy of the db and in the copy delete all the forms, reports, modules etc to just leave the tables. Compact the copy and move to the network. This is your Back End

Now go back to your original db and use the External data function to link to your tables in the db on the network. Note: If you still have Name Autocorrect running, it is better to link first (which will add the linked table with a 1 at the end) and then rename by removing the 1 to replace the existing table. Otherwise just delete the existing tables and then link. Finally compact this db - This is your Front End and should be copied to users machines.

This will also make it easier to update the front end since you can make changes and release a new version to users as required - the only time you will need to bump users off the system is if you need to make design changes to the Back End.

 

[nemPyong]

Thank you so much for your answers!
I've tried it, and it worked very well
I used external data > access, and have 2 file: BE (back end) and FE (front-end), and did what you said

But I wonder... linking should not be the same as importing right? But why did those files have same size? I thought the FE that only consists of form and the link will have the smaller size, and the bigger one is BE that contains the real table and data... It's as if linking is the same importing (copying all the table and data) but with link?

 

[CJ_London]

If you compact the databases, the FE will become significantly smaller

 

[nemPyong]

I'm sorry, could I ask again?
Just as you said, compacting really does make the DB smaller!
How could? What was it that access removed?

 

[CJ_London]

when you build forms and enter data that takes up space and increases the size of the db. When you delete data, forms or controls although the space is released it is not reused.

When you compact the database it effectively copies everything (except the spaces) to a new db.

There is a bit more to it than that (re indexes etc) but in principle that is it.

Compacting is worth doing on a regular basis - perhaps once a month for your back end, but your front end will not change in size until you make further changes.