Solved Running a split database using the MS free Access Runtime software (1 Viewer)

[PaquettePaul]

Hopefully, I will get my thoughts down correctly.

I have a database that will be placed in a multi-user environment. So, best practice is to split the database into software and database files. Then the software version gets saved as an executable/compiled version so that end users cannot use or change the software. The database file gets saved on a server and the executable get stored on the client workstations linked in the office network. This approach also allows new versions of the software to be passed out without impacting the actual database (unless the database structure itself is also being modified).

My understanding is that when the user starts their executable, they can select/connect to the actual database files on the server using a configuration setting.

The problem seems to be that the site where the application is being stored will only be using the free runtime version of access rather than a developer version. From our initial look at this, the ability to link the executable access file to the database file is only available with a developer version of Access.

First question is am I correct in that I cannot link a split database that resides on different computers if i only have the runtime version installed?

Second, if I am wrong, do you have any instructions or reading material that I need to look at to resolve my dilemma?

As always, help is very much appreciated.

 

[CJ_London]

First question is am I correct in that I cannot link a split database that resides on different computers if i only have the runtime version installed?

you can using vba. Plenty of examples about - here are a couple

Connecting to access backend from access 2013 frontend using VBA

I have 5-6 clients to whom I will be selling my Access based Product. Where there is Back-end Database file (Password Protected). Access accdr Front-end file which saves data in back-end file. The

stackoverflow.com

Automatically relink Microsoft Access tables | Microsoft 365 Blog

Automating the relinking of tables just makes good sense. This is especially true if you are distributing your database to others. It can save you a lot of headaches, trouble, travel, and time. You do not have to be physically present, nor do you need to remotely access another computer...

www.microsoft.com

They probably will need some modification to meet your specific requirements.

just google something like 'access vba link to back end file' to find more

Assuming all users are link to the same BE then if you link using a UNC path rather than mapped drives, them your FE shouldn't need to be relinked anyway

 

[PaquettePaul]

Thanks. I will try these out

 

[PaquettePaul]

Hmmm. I thought that if I save the database as accde (file saved into an executable only file) then no one would be able to view the code. Is this not correct.

Delivery of new versions will be somewhat remote with installation instructions. I am developing the app in Pennsylvania and send it to my older brother in Ontario, who does the testing and acts as user rep, and when he/we are satisfied, the database will be stored as an accde and split, then sent on to my other brother in Alberta. Once in Alberta, he will store the two files on his office workstation. The brother in Ontario has remote access to the computer in Alberta and may have to do the install and configuration. Brother in Alberta is a great flyer/instructor but not computer savy.

It is expected that other instructors will access the application, although hopefully through the office computer rather than their own. I agree that there is a possibility of someone mucking about with the database or deleting the files but with daily backups, the damage should be minimal (maybe six flights a day with paper backup). Currently everything is done through a spreadsheet (yikes) But the needs have outgrown the spreadsheet capability.

By going with accde, I was hoping to at least protect the software rights by making the code inaccessible. Is this the correct approach?


I will send your comments about the batch file installation to my brother in Ontario.

 

[CJ_London]

I thought that if I save the database as accde (file saved into an executable only file) then no one would be able to view the code.

correct - you cannot view the code in .accde. It's just not the same a an executable file (.exe) which a) is fully compiled and b) does not require a 'host' application - such as access.

With regards runtime - if you are expecting some users to install runtime rather than a full version of access (or you supply as .accdr) then it is important then you are aware that users do not have access to the navigation window or full ribbon (which is good,) and perhaps more importantly shortcut menus (i.e. on right click) are disabled. If you need them, you need to write your own

 

[PaquettePaul]

Btw, I just tried out the first sample code to reselect a backend database and it worked great. The only thing I changed was to get the user to select the backend database first using a file finder dialog.
you guys are really helpful.

 

[PaquettePaul]

Yes, the reconnect to database function is password protected in the code as there is no database.

 

[gemma-the-husky]

Hmmm. I thought that if I save the database as accde (file saved into an executable only file) then no one would be able to view the code. Is this not correct.

Delivery of new versions will be somewhat remote with installation instructions. I am developing the app in Pennsylvania and send it to my older brother in Ontario, who does the testing and acts as user rep, and when he/we are satisfied, the database will be stored as an accde and split, then sent on to my other brother in Alberta. Once in Alberta, he will store the two files on his office workstation. The brother in Ontario has remote access to the computer in Alberta and may have to do the install and configuration. Brother in Alberta is a great flyer/instructor but not computer savy.

It is expected that other instructors will access the application, although hopefully through the office computer rather than their own. I agree that there is a possibility of someone mucking about with the database or deleting the files but with daily backups, the damage should be minimal (maybe six flights a day with paper backup). Currently everything is done through a spreadsheet (yikes) But the needs have outgrown the spreadsheet capability.

By going with accde, I was hoping to at least protect the software rights by making the code inaccessible. Is this the correct approach?


I will send your comments about the batch file installation to my brother in Ontario.

The source code is removed, and the application is turned into a pseudo-executable. It's not quite the same as a .exe file though, as the executable access mde/accde still needs the access environment shell, if you will.

It ought to be pointed out also that the mde/accde is by no means fully secure. Have a look at the demo on everything access for example. I use code from that site to remove the information that can be used to actually reconstruct your original source code.

@Pat Hartman just mentioned this last point. It's certainly worth using something that obfuscates attempts to reverse engineer your code.

 

[gemma-the-husky]

The .accde is NOT an executable. Please don't call it that. That only confuses people into thinking the .accde is something it is not. And as I carefully explained, the .accde is not even close to being an executable.

I changed the description to pseudo-executable, although I had previously qualified the description anyway.