How to creating one mdb file to exe file
- Thread starter dragos
- Start date
Cosmos75
Registered User.
- Local time
- Today, 01:07
- Joined
- Apr 22, 2002
- Messages
- 1,281
You can't create an .exe file. You can create a RUNTIME VERSION with the developer edition of Access that allows to distribute a runtime version of Access. The runtime version of access only allows you to open database files and not design or change the design of a database file.
http://www.access-programmers.co.uk...p?s=&threadid=45977&highlight=Runtime+version
http://www.access-programmers.co.uk...p?s=&threadid=33307&highlight=Runtime+version
http://www.access-programmers.co.uk...p?s=&threadid=45977&highlight=Runtime+version
http://www.access-programmers.co.uk...p?s=&threadid=33307&highlight=Runtime+version
Last edited:
jeremie_ingram
Registered User.
- Local time
- Today, 01:07
- Joined
- Jan 30, 2003
- Messages
- 437
I have the MSDE installed and have created a few items with it for use throughout my agency. Here is the direct qoute from Microsoft.
"Differences Between Full Microsoft Access and the Run-Time Environment
Users of your application work in an environment that combines the built-in features of Microsoft Access with the objects that you create. Unlike applications created with Microsoft® Visual Basic® or Microsoft® Visual C++®, applications created with Microsoft Access are not compiled into a single executable file. Access applications work by running your application's database file (.mdb) in the Access Runtime environment with user profiles, which are stored in the Windows registry.
While an Access application is running, it might not be apparent which elements of the environment your application supplies and which elements the run-time environment supplies. Because your application has its own look and feel, it might not even be apparent that Microsoft Access is running. Although Microsoft Access Runtime applications are identical in most respects to full Microsoft Access applications, there are some differences that can affect how you design and develop them:
The Database, Macro, and Visual Basic Environment windows are hidden, and all Design views are hidden, including the Filter windows.
Built-in toolbars are no supported, but you can add custom toolbars to your application.
Your application uses its own Help file.
Some windows, menus (including shortcut menus), and commands are hidden or disabled.
Visual Basic error handling is required. Errors that are not handled by your code will shut down the application without warning. For this reason, the use of macros is not recommended.
Certain keystrokes and key combinations are disabled.
Note If your application uses dynamic data exchange (DDE), you can specify either Microsoft Access or the application name specified by the AppDDEName user profile setting as a valid DDE application name. The run-time environment will respond to both. "
So it is true that you are NOT creating an actual .exe file, but if you set it up properly it is difficult to distinguish that from the end user point of view.
I you would rather create a TRUE .exe file I would suggst looking into either C++ or VB (6.0 or .NET). They will allow you to create applicationss that can function well with MS Access.
"Differences Between Full Microsoft Access and the Run-Time Environment
Users of your application work in an environment that combines the built-in features of Microsoft Access with the objects that you create. Unlike applications created with Microsoft® Visual Basic® or Microsoft® Visual C++®, applications created with Microsoft Access are not compiled into a single executable file. Access applications work by running your application's database file (.mdb) in the Access Runtime environment with user profiles, which are stored in the Windows registry.
While an Access application is running, it might not be apparent which elements of the environment your application supplies and which elements the run-time environment supplies. Because your application has its own look and feel, it might not even be apparent that Microsoft Access is running. Although Microsoft Access Runtime applications are identical in most respects to full Microsoft Access applications, there are some differences that can affect how you design and develop them:
The Database, Macro, and Visual Basic Environment windows are hidden, and all Design views are hidden, including the Filter windows.
Built-in toolbars are no supported, but you can add custom toolbars to your application.
Your application uses its own Help file.
Some windows, menus (including shortcut menus), and commands are hidden or disabled.
Visual Basic error handling is required. Errors that are not handled by your code will shut down the application without warning. For this reason, the use of macros is not recommended.
Certain keystrokes and key combinations are disabled.
Note If your application uses dynamic data exchange (DDE), you can specify either Microsoft Access or the application name specified by the AppDDEName user profile setting as a valid DDE application name. The run-time environment will respond to both. "
So it is true that you are NOT creating an actual .exe file, but if you set it up properly it is difficult to distinguish that from the end user point of view.
I you would rather create a TRUE .exe file I would suggst looking into either C++ or VB (6.0 or .NET). They will allow you to create applicationss that can function well with MS Access.
Similar threads
