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, 05:53
Joined
Mar 24, 2013
Messages
92
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.
 
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....
 
After a delay of a few days, I've received an update on this :

He's still encountering this same problem (ie as per original post).

The database did Compile. I made sure of that before I forwarded it on to him.

Prompted by me (at your suggestion, CJ_London), he checked for the existence of the 'Save As' dialogue behind existing windows, but didn't see it.

I'm not quite sure how to proceed with this.. I feel that I've lost sight of what it is I need to do - or he needs to do - to allow him and his colleagues to start using the database.
 
Users should not be asked to split a database. If you insist on sending them a database for testing that is split, then you split the db and send both the FE and BE. If the users are going to be sharing the BE, then the user needs directions on where to create the folder for the BE and how to place the BE there. Then you need to include relinking code in the FE. When the FE opens, it needs to check to see if its links work. If they don't, then it opens YOUR custom relink form that has good directions for navigating to the correct BE. Because you are entrusting the user with this, you also need verification code in the FE that compares the version table in the FE with the version table in the BE to ensure that they match because it is too easy for users to mess up stuff like this and you could have one person end up using an old BE.

Once the administrator has gotten the FE/BE to link correctly, he distributes the FE to each user so that each user has his own personal copy. There are good and simple ways to do this but for a limited testing pool, he can deal with the manual distribution. The users should all store their copy of the FE on their C: drive. Assuming everyone has the server drive mapped as the same drive letter, the FE will work for everyone.
 
After a delay of a few days, I've received an update on this :

He's still encountering this same problem (ie as per original post).

The database did Compile. I made sure of that before I forwarded it on to him.

Prompted by me (at your suggestion, CJ_London), he checked for the existence of the 'Save As' dialogue behind existing windows, but didn't see it.

I'm not quite sure how to proceed with this.. I feel that I've lost sight of what it is I need to do - or he needs to do - to allow him and his colleagues to start using the database.
Well if he can trust his colleagues, they could just use the accdb?
You could make the accde and send that to him?

Does the FE compile for him?

If any bugs are discovered or new features required, who is going to work on those?
 
When you have to manage users remotely, you also need to get some meeting software. For years I used GoToMeeting which is very expensive but recently, I've switched to Zoho which is dirt cheap and is almost as good. The only downside to Zoho is the way they handle recurring meetings but price wins given my current meeting requirements.

Using Zoho, you can send your user an invitation and the two of you can meet. You can ask for control of his machine and you can do what you need to while he watches.
 
When you have to manage users remotely, you also need to get some meeting software. For years I used GoToMeeting which is very expensive but recently, I've switched to Zoho which is dirt cheap and is almost as good. The only downside to Zoho is the way they handle recurring meetings but price wins given my current meeting requirements.

Using Zoho, you can send your user an invitation and the two of you can meet. You can ask for control of his machine and you can do what you need to while he watches.
 
I think Pat brings up a very relevant and good point. Finding a way to remotely collaborate and potentially remote control and all that kind of stuff is going to be a big deal for you now and in the future and it will only get more that way so start experimenting now and find the tools that best serve your needs.
 

Users who are viewing this thread

Back
Top Bottom