Splitting Database (1 Viewer)

Hi
I would like to know in general what I have to do splitting a database. In my scenario I want to deploy my database. Many suggests to split it. Well If I do that I got two files: one .accdb (front end) and one .BE (back end).
Shoul I keep them in the same installation directory?
What should I do if I do improvments on the on the database? Keeping the .BE safe and modifying the .accdb is that enough?
Sorry for to be so newbie but I need to clarify.
Many thanks

the backend goes on the server where everyone who needs it, has read/write access to the directory.

A copy of the front end goes to each user - make sure you have relinked your front end to the backend on the server before distributing.

With regards improvements, depends what they are. If you need to modify the backend table designs, you will need to do this when everyone is off the system.

With front ends, keep a master copy and when modifications are made, send revised copies to all your users.

Whether it is enough depends on what you consider is enough. If you don't want users to mess with the backend you will need to protect it in some way - password protection, set hidden properties to true for example, although this won't deter a determined user - you would need to use a different backend - SQL Server/Express, MySQL for example

For the front end, converting it to an accde will protect the forms, reports and modules. For queries users will only be able to change their own copy, but again you can do things like hide the navigation window.

Database security is a whole subject in itself and there are hundreds of threads on this subject in this and other forums - google 'secure access database' or similar to find out more

Thanks CJ London.
More clear now.
But one point and enough. I got to deploy on desktops so there is no server. If I keep in the same directory both Front end and Back End is it the same?

You only have one backend which all users share. if you put the backend on a users machine, other users will not be able to share the data unless they also have access to the that users machine.

However this has many issues - what happens if that users machine is switched off for example.

If you don't need to share data then each user can have their own front end and backend on their machine. It is still better to keep separate front end and back ends for maintenance purposes.

I have recently done the same.
I keep the back end in the same folder as the front end.
No problems.
To modify tables - open back end,
To modify everything else - open front end

Keeping your FE and BE on the same machine for each user implies multiple ACTIVE copies of the BE which implies DIVERGENCE of the BE from each other starting from that point in time at which you made the copies. There are ways to reconcile multiple divergent databases but they add to your overhead a LOT. The term used for this case is "synchronize" when applied to Access databases, and that is another topic to look up.

You claim to be inexperienced (and we have to trust you on that.) You need to trust US when we say that keeping copies of the BE on multiple machines will lead to serious headaches and sleep deprivation, growing worse in direct proportion to the number BE files to be maintained.

My best advice is to "sacrifice" a machine to become the "server" for the BE file. Remember, if you are using Access, it only has to be a passive file server, not something more active like SQL or ORACLE servers. This machine can be used for other things perhaps, but the key is that it can never be turned off during the hours during which your user base wants to get into the database application. "Sacrifice" also because you will have to "appease the Access gods" by backing up this machine (or at least the shared folder holding the BE file) on a VERY regular basis, to the point of being nearly a ritual. You will need to do other maintenance on this machine during lulls in your business -perhaps during an off-hours maintenance period. At least the Access gods don't require sacrificing a virgin every so often.

You can also keep the current, most recently released/updated copy of the FE on that same machine but it would be a REALLY good idea to determine that system's name and add code to the FE file to stop it from running directly on that system. If you have an opening form, the .FormOpen routine of that form is a good place for the test. If you catch a user directly running the FE from the shared machine, some serious knuckle-slapping with a hard ruler would be a good idea.

There is a techie reason for all of this. By putting the FE on each user's machine with the queries, forms, reports, macros, and modules in the FE, you prevent the case where two users opening the same FE file from the same server at the same time incur some type of file locking interference. If the tables on the BE are shared but everything else is in the FE and NOT shared, you have eliminated file locking issues for everything in the FE. If you then use OPTIMISTIC LOCKING (look up that help topic), you further reduce the frequency of BE locking. You can never truly eliminate it, but you can reduce the heck out of it. This is a good thing to reduce.

The Doc Man, thanks a lot

When an application requires to be deployed in a multi-user environment, it is very convenient to split the database into two groups. The first contains the client application: database with forms, queries, reports, macros, and modules. The second contains only one or more database tables. The client application is distributed among all the workstations and connects to one or more databases stored on the server.

It is important to clarify that the term server is not very suitable for "Jet Engine and Access Database Engine" databases (mdb, accdb, etc) and it only refers to a shared folder on the network because no data processing task is executed on the server, but on the client.

By implementing the client – server design:

• All users share the same information.
  
• Maintenance tasks may be carried out in the application objects (forms, reports, etc,) without placing the database offline.
  

Perhaps the easiest method to implement this design consists of attaching all tables of the database server in the client application. For security and performance reasons, this method is not recommended for real server databases like a SQL.