Simulating Access Database as .Exe (1 Viewer)

Hi Everyone,

As requested, i am sharing an idea of simulating a Database for a .exe file. It is common knowledge that people would like to have their database distributed as a .exe but there is no facility for this. I tried this out on a small db a little while ago and all seems well.

Idea.
The idea is to make it look as though you have distributed a .exe and not a database file which isnt that hard to do.

What You Need.
A Screen saver program like Splash Screen Machine ( google search )
A compiler i.e wise, MSI or other good program
your database in .mdb or .accde (NOT SOURCE CODE)
runtime

Process.
1. find a location for your database file to be installed. somewhere pretty deep in the system C:\Users\UserName\AppData\Local\Microsoft\Common\Versitile\CleanUp\Data
Note: Common\Versitile\CleanUp\Data are created folders and all hidden

2.Place your completed Database program here.
( reason will be explained further down )

3.Open splash Screen program and follow settings. you can use either Flash or image and set the timer for splash screen to be shown. i set the splash screen for 4 seconds.

4. set the application timer to 3 seconds.
( this means the database will start before the splash screen disappears )

5. set the application to open to the database file you placed in the hidden folders

6. create your splash screen.
( point it to a folder in Program Files where you want the final folder to be placed during the installation i.e MyProgram and name the .exe something related to your program i.e MyProgram.exe ).

7. run the compiler and include the splash screen program, the database and runtime.
( some installers cannot include the runtime but others can install more than one program together by installing program 1 and then installing program 2 etc so it would install the splash screen file, install the database file then run the runtime installer )

this then creates a standard Program files folder after install called MyProgram and inside this is a .exe called MyProgram.exe when this is clicked. the splash screen opens and the database opens giving the impression there is only one program. the desktop & start menu shortcuts only point to the splash screen .exe and the user would probably be unaware there is a database even present. As the database is run using the runtime, there is little or no splash screen however to be completely sure, make you splash screen image non transparent and bigger than an Access splash screen. as the splash screen runs for 4 seconds and the database is started after 3, you should hide any trace of the access screen behind you fake one. both are screen centred.

Make sure your database is set to force runtime so on the off chance a user does find it, they cant open it anyway.

A downside is you have to buy the splash screen program. they are not expensive and there are a few around but probably worth getting.

i will update here when i get a good list of compilers.

Nigel

While I haven't tried it, I did notice that Visual Studio has a template for Screen Saver builtin, and there are express editions where you can compile your editions.

That said, here's an interesting idea: Instead of hiding the database, can it be compiled into the screen saver builtin a la BLOB data type like one can do with any SQL backend to store documents, spreadsheets and even executables inside?

The thing, though, would be that it would have to be allowed to grow and shrink, since the file can change during the execution and have to be made sure that it doesn't overwrite the container itself or something like that...

I looked at that briefly before but didnt get anywhere. you can create splash screens in VS but i couldnt find where to link or attach a databse for compiling.
heres another thought
with VS, you cannot convert a complete .mdb or .accde but you can attach the data. so couldnt you have the data in the .exe as a sort of back end and when the .exe is started, the Fe which isnt part of the .exe is opened and writes its information?

im not that familiar with VS

Nigel

I see.

When I have free time, I may play around with that idea.

As for data in compiled state, the thing is that you still have to present it in a useful format. If we just saved it as a CSV, I'm quite sure we'd see serious performance degradation, and if we just left it in native Jet format, it would be just basically a Jet backend which still can be accessed via other database or providers.

I suspect that if it were sensible then Microsoft would have provided the means of doing it. The main problem that I see is that a database does not normally stay static in size but often increases as new records are added. By allowing a .exe file to change in size would open the door to malicious attacks that might be difficult to detect. Having the data as a separate file would appear to defeat the object.

Rabbie, you make a quite excellent point.

I try to remind myself that 99% (actually 100%) of ideas I (or anyone else) has, someone else has already thought of it before.

One more thing I feel need consideration: We have to remember that this is a file-based database server where there are no daemon handling the files which if there were, it would be easy to restrict permissions to data files through Windows security model. As such, everyone requires full Windows permissions to the file even if they are supposed to read only, or maybe edit only portions of it.

The .mdb/.accdb, etc are containers of data, code, and object definitions. You can compile code but not the others. To enable true compiling would require changing the nature of the .mdb.

hi,

Here's a thought. Everyone always mentions about a .exe file not being expandable. If your database is split then surely it's only the backend that would expand as the frontend doesn't hold data. At the end of the day, it's your code and forms you want to protect and the data could be encrypted to the external tables so even if you could just convert the front end would be a great improvement.

Ns

Afraid that won't do, because if I'm not mistaken, the file still can expand/shrink due to local variables being used and the fact that we're still using Jet database which may do managing of data that can affect how file can change.

It would certainly be less, yes, but I don't think this is foolproof.

anyone that have a good alternativ to Splash Screen Machine?