Problems creating 'front-end' portion of split database (ie. no 'Save As' dialogue after clicking 'Make ACCDE' and 'Save As' button)

alan2013

Registered User.
Local time
Today, 13:22
Joined
Mar 24, 2013
Messages
91
I have recently created an Access database for an acquaintance, sending him the 'working-copy' (.accdb format) file, and instructing him on splitting the database into 'back-end' and 'front-end'.

It seems he's been able to create the back-end (‘Database Tools’ --> ‘Move Data’ section --> ‘Access Database’ --> ‘Split database’).

But he insists he's then encountering problems creating the 'front-end', specifically : in the 'working-copy' database, he clicks on ‘File’, then ‘Save As’, then ‘Make ACCDE’. But when he then clicks the ‘Save As’ button, apparently noting happens, Access becomes unresponsive, and he has to close Access using Task Manager. As I understand it, a 'Save As' dialogue should open up, and he should have the opportunity to save the accde file.

I'm not all that familiar with splitting of databases. Can anyone provide some guidance on what the problems might be here, and how to work round it. Thanks in advance.
 
Why don't you try splitting it and send him both DBs
To make an ACCDE the DB needs to be able to compile? Does it?
 
When you use the wizard to split the database, it automatically creates two files: the BE and the FE. So, it sounds like your friend didn't have any problems creating an FE. Rather, it sounds like the problem is with creating an ACCDE. Why are they trying to do that? If that is the problem, then you'll have to check your VBA code to make sure it can compile before giving it to them.
 
I'm not all that familiar with splitting of databases.

There is no need to create a .accde for a front end. All it does is provide a compiled code version so forms/reports/modules cannot be modified. User will still be able to see and modify tables and queries.

Splitting a db is normal and recommended practice. Definitely in a multi user environment, not so necessary for a single user but runs the risk of losing everything is something goes wrong. At least if the db is split, the BE data should not be affected and you would have a spare copy of the FE to simply replace the corrupted FE.

. But when he then clicks the ‘Save As’ button, apparently noting happens, Access becomes unresponsive, and he has to close Access using Task Manager.
It is possible the app is waiting for a prompt - and that prompt may be hidden by the existing access. Shouldn't happen but it does on occasion. The prompt will typically be located in the middle of the screen, so ensure access is not covering that - resize it as required.
 
FWIW, I have encountered failures making .ACCDE files on my Arm-based Surface Laptop 7 with Access running under emulation, while there are no issues with the same file on an X86 device. (Everything else is fine; I use Access on this device daily.)

I mention it just in case he might be running Windows on Arm.
 
I don't agree that there is no need to create an accde of the front end.

If you want to protect your design elements, it's well worth doing. It also prevents users modifying the front end.
 
It also prevents users modifying the front end.
It should but it doesn't. It prevents modifying forms/reports/modules but Not macros/queries/tables. Rename the .accde to .accdr for one small extra layer of protection. No objects in an .accdr can be opened in design view. The users can still do great damage to an .accde. At least the .accdr prevents all accidental damage.
 
Over all the years of using Access, I have never used the so called Wizard to split my databases. I have never seen the point in it.
On a new application I'll keep everything in one .accde as I find it can be easier in the early days. Then I'll create a new BE database and import just the tables that are required in the BE. Then delete them from the FE. Compact both and invoke my re-linking function in the FE. Job done.
 
Ah, but you have your own relinking function. Most people do not, including me, so a quick few clicks gets me a BE and FE from a single DB.
 
Over all the years of using Access, I have never used the so called Wizard to split my databases. I have never seen the point in it..

Splitting a database is mostly for multi-user deployments. Having a shared back-end database with front-end logic deployed to workstations improves performance and scalability.
 
Splitting a database is mostly for multi-user deployments. Having a shared back-end database with front-end logic deployed to workstations improves performance and scalability.
I think @Cotswold meant the actual use of the Split wizard.?
 
I also don't give users a split db for early testing. It isn't until we get to multiple users testing that I split the db and have them test with the test version of the BE at the same time to make sure that works. Single user testing doesn't need to use the split FE/BE
 
Yeah, if the problem was only with splitting it, then just don't use the wizard at all. Create a BE manually and put the tables in it. Link from FE to BE, delete tables from FE. Problem must be with making accde, which as some have said isn't necessary unless you find it so.
 
Over all the years of using Access, I have never used the so called Wizard to split my databases. I have never seen the point in it.
On a new application I'll keep everything in one .accde as I find it can be easier in the early days. Then I'll create a new BE database and import just the tables that are required in the BE. Then delete them from the FE. Compact both and invoke my re-linking function in the FE. Job done.
It truly is making a big deal out of a fairly small thing. Relinking code can be written in 5 min and reused many times.
Tables can also be pasted as links if I recall correctly....
 

Users who are viewing this thread

Back
Top Bottom