You shouldn't need any VBA to split a database; all you're doing is linking the tables in from a repository database into a desktop version.

However, there's additional VBA in modules. If you can open the VBA editor, you should see the modules listed at the bottom of the Project window on the left.

Click the Debug button on the toolbar and then click on Compile. The database will jump to the first code error it comes across, including any in a module.

Option Explicit
Compile

Hi Peter
Try Rick's Tech Help Video  https://599cd.com/blog/display-article.asp?ID=1373

John

@ Peter Are you saying you get a "Subscript out of range error" when splitting the database? Or after when you try to run you front end application?

Range errors are normally Run Time Errors (RTE) and happen at run time, not at compile. Depending on the error handling in your procedures, you should get a debug button which will take you to the problem code line. That said, I have had times where RTEs occur and just give a message without a debug option (if I recall correctly), in which case, you want to set a breakpoint at the start of your first suspect procedure, and just F8 through each line until you get to the RTE.

I've found having this kind of status display (example in next post) in all my form/{report} procedures invaluable during development, and when getting a bug report from a user.

@Thomas, yes I get the message when splitting the database with the tool in Access.

Are there any errors in your code?
Debug -- Compile

Thread: Subscript out of range

@ Kevin R. I'm curious, why do you think a code bug would cause the Database Splitter tool to fail? I can't imagine why Access would care when the idea is just to move objects to different db files.

@ Peter S. I've seen some strange things happening recently with MS Access upgrades. Has one been done on your machine recently? Are you able to decompile and recompile the original .accdb file before it's split? Just to test Kevin's suspicion.

@Thomas I've seen just about everything break, even splitting the database, when the compile is broken.

At any rate, compiling is a 3 second fix so no reason not to do that :).

@Kevin: the answer I'm am (still) looking for with this topic, is there a central place in the database were I can debug--compile ALL the written VBA code used in the database. As I see it, I'll have to check the VBA on each separate form.

@Thomas: I don't have a subscription or updates, I have MS Office proffesional plus 2021

Peter, debug->compile does compile the entire database. It will stop if it finds a bug on any form, then you fix that bug and compile again, it may find another bug on the same form, or on another form, or complete with no errors. You just keep pressing it until it finds no errors.

I open the code in my databases by pressing Alt F11 with the database open (it does not matter where or what you are open to). Then choose Debug on the menu and Compile to compile all the code in the database.

@ Peter, I also have Office 2021, and updates seem to run even without my initiating them from the File>Account>Update Options>Update Now. How do I know this? About a year ago, I wrote down the Build number after an Access update, then checked it a few months later when doing another manual update, and they weren't the same.

@ Joe I suspect, no real proof other than observation, that doing a Debug>Compile will only do procedures that Access thinks have changed. Why do I think this? After doing a decompile, the compile takes a second or two, longer it would seem than without the decompile.  Also, I've had odd bugs that occur after a compile or new code, that magically disappear after doing a decompile, even without doing a post compile.

@ Peter, Adam S. previously provided a link (in blue word compile) in this thread that shows how to decompile and recompile.

If a simple compile doesn't show any errors, run down the Troubleshooter.