How can I make an EXE file from an MDB file 1

[nagyf]

Gentle Forum Members!

How can I make an EXE file from an MDB file?
I have to give out something written in Access 97 to users not having Access.

Another solution would be to rewrite all forms and mudules in Visual Basic and compile the VB progam to EXE.
Its disadvantage it that we have to rewrite almost everything. I see that we cannot copy the form definitions from Access to Visual Basic? Is it true?
Is there any way to reuse Access forms and reports from Visual Basic?
Regards
Frank
Ferenc Nagy
|\ /~ ~~|~~~ nagyf@alpha0.iki.kfki.hu Fax: (36-1)-392-2529 New!
| \ | | Institute of Isotope and Surface Chemistry
| \ | -+- 1525 Bp. POB 77. Tel. 36-1)-392-2550
| \| |

http://alpha0.iki.kfki.hu/~nagyf

`-' ' `-' "The goal of the life is the struggle itself"

 

[AlexMidd]

For the first option you need to have the "Developer" version of Access, so that you can compile run-time apps based on your DB. The second option requires additional software to allow for transfer of reports and forms to and from Visual Basic.

Both these options involve purchasing additional/upgraded software and cannot be done in the Professional version of Access. Have fun! )

Alex Middleton

 

[nagyf]

Alex,

I have the required version of Access.
Do you mean the compilation to ->MDE?
What is the regular process to make an executable?
Which files do I need to pack in the installation CD for a
remote user having neither Access nor Visual Basic?
What are the functions or Access tricks which I should avoid if I want to make MDE or EXE from the MDB?
Thanx
Frank Ferenc Nagy
|\ /~ ~~|~~~ nagyf@alpha0.iki.kfki.hu Fax: (36-1)-392-2529 New!
| \ | | Institute of Isotope and Surface Chemistry
| \ | -+- 1525 Bp. POB 77. Tel. 36-1)-392-2550
| \| |

http://alpha0.iki.kfki.hu/~nagyf

`-' ' `-' "The goal of the life is the struggle itself"

 

[AlexMidd]

Sorry Ferenc, I cannot answer those questions as I do not have the Developer Edition with the ability to produce Run-Time apps, and have never done this before (this is not the same as creating an .mde file).

(P.S. How's it in Magyarorszag? I spent a lovely ten days there in Eger back in May. I really loved it there, especially the Hortobagy area).

Have fun! )

Alex Middleton

 

[Oppenhiemer]

Hi -

Its not actually possible to create an EXE file right from an Access Database (unless you port it to VB of course.) The alternative is to obtain the Access developers toolkit as AlexMidd sugests. This allows you to create a setup program to distribute your database with the runtime version of Access so your customers can run it even if they own no office products.

The problem is - that as far as Im aware you can no longer get the Developers toolkit for Access 97 - but perhaps if you can get hold of a second-hand version it would solve the problem. Failing this, you will need to buy the next version up - which as far as I know is still Office 2000 Premium (cost me about £450 but this was a year ago so it may be cheaper now.)

In this version of office, the ODE Tools (developers tools) ship with the office suite. But please check this by talking to Microsoft (as one unfortunate chap in another forum purchased the Office Premium - but did not receive the extra ODE Tools that were supposed to come with it.)

I own both version of the developers toolkit for Access so the info Im giving should still be correct - but please check with Microsoft before you buy anything! They have a tendancy to change their products without much notice!

Hope this helps..

 

[JoaoTL]

Nagyf, When you pack a DB with Office Dev, the moast valuable advantage you have is include the Access Run-Time to make the DB independent from Office. This dosen´t close the DB, the DB remain equal to original, so you have to make a MDE. You can Make a EXE from a MDB, bacause if it was possible than Microsoft had a lot to think how to sell Visual Basic.
-------------------------
Regards
JoaoTL
-------------------------

 

[nagyf]

1. To AlexMidd
On you have been in Magyarország!
I have spent two weeks in August near Eger, in village Noszvaj. If you are interested in it please write to nagyf@iki.kfki.hu. I have scanned some photos. I intend to organize them by IrfanView somewhere under

http://www.iki.kfki/hu/~nagyf.

2. Yesterday I wrote a Visual Basic program which called an Access database.

I have had strange experiences
A.
dim rst as recordset
...
set rst = dbs.OpenRecordset("USER",dbopendynaset)

caused an execution error.
I had to change the type:
dim rst as object
...
set rst = dbs.OpenRecordset("USER",dbopendynaset)

Why?

B. I have tested in within the VB 6.0 environment and as standalone exe on my PC1 then I tried to run it from the server where neither Access nor VB are installed.
I have got a message that a DLL is missing. I copied it to the forled of the exe file. I got a message that the version of another DLL (OLEAUT32) is not the proper.

Question: I have to develop an installation process working on different remote computers. How can can avoid DLL version incompatibilities? In other words:
User uses Version A of X.DLL in program OTHER.EXE, MY.EXE program uses version B of it. If I simply replace his/her X.DLL with my version then MY.EXE will work but OTHER.EXE won't.
My preliminary idea: What if I rename Version A of X.DLL to XA.DLL, and incude it on the installation disk? XA must not be installed to the system folder but rather the folder wher MY.EXE should be.

C.
I have used the same references as the VISDATA demo.
Maybe I need not all of them?
Any help would be appreciated.

Ferenc Nagy
|\ /~ ~~|~~~ nagyf@alpha0.iki.kfki.hu Fax: (36-1)-392-2529 New!
| \ | | Institute of Isotope and Surface Chemistry
| \ | -+- 1525 Bp. POB 77. Tel. 36-1)-392-2550
| \| |

http://alpha0.iki.kfki.hu/~nagyf

`-' ' `-' "The goal of the life is the struggle itself"

 

[AlexMidd]

Well, just a thought, do you have Microsoft Access Object Library and Microsoft DAO Object Library selected as references in your VB project? I presume you would but the problem you mention in A does not occur in my projects, so I am not sure why it is happening to you.

As for B, I understand the problem. My bugbear is the Comdlg32.ocx file, which runs the Common Dialog, and the same problems occur when different apps on the same machine need different versions. I have doen what you suggest, i.e. tell the installation program to install to another directory, that way it doesn't interfere with the version used by the other apps on your computer.

I'm not sure about C, as I have not used Visdata, but check for the libraries I mentioned above - it may be the problem.
Have fun! )

Alex Middleton

 

[Oppenhiemer]

.. I know this is not going to be very helpful advice but here goes.. I would seriously only use Access to help you quickly develop working prototypes. Once you have the basic model - re-write it in a more robust environment .

One of the main critisisms of Microsoft Visual Basic and Access (and indeed all of Microsofts software) is their relience on ActiveX and DLL's. The problem is that you get into big problems either beacuse of incompatible versions or registratioin problems.

Microsofts slavish dependance on this brocken technology is the reason behind many software problems. I have been using Access to develop Commercial Database applications for a couple of years now - and after lurching from one bug to another - have finally come to the decision that if you want a trouble-free life - dont use Access.

I am curently in the process of re-writing my apps using Borlans (Inprise) Delphi.

Cheers..

P.S In direct relation to the problem - Check in the "References" section to see if there are any "MISSING" statements. It does sound like you are referencing an object either of a different version - or that is not properly registered at all.

 

[nagyf]

Alex, I had similar adventure with COMCTL32.DLL bugbear:
I installed a program attached to a newspaper on a CD. It overwrote that file with an older version.

I am afraid that in my case OLEAUT32.DLL is not only directly referenced but from another MSVB*.DLL-s, too. Therefore I have to edit with Norton Utilites these files, to replace all occurences of OLEAUT32.DLL to for example OLEAUTNF.DLL in my installation package.

.......

Rewrite in Delphi? Within two month including its purchase and learning?


I know that Access in not the proper tool.
"Its is designed for American housewives to account their kitchen money."[color]
I used to be
a Hewlet-Packard 3000 GX programmer, user of TurboImage under opsys MPE. But the institute had not money to upgrade within this hw/sw direction. We ha d to accept money from a crazy man from the International Atomic Energy Agency in Vienna who supported Access.

The niggard pays twice.
That man has been fired from IAEA but we have to suck his ideas.
Such is life. Ferenc Nagy
|\ /~ ~~|~~~ nagyf@alpha0.iki.kfki.hu Fax: (36-1)-392-2529 New!
| \ | | Institute of Isotope and Surface Chemistry
| \ | -+- 1525 Bp. POB 77. Tel. 36-1)-392-2550
| \| |

http://alpha0.iki.kfki.hu/~nagyf

`-' ' `-' "The goal of the life is the struggle itself"

 

[Oppenhiemer]

I guess its not a short-term option - no. Circumstances must dictate your decision.

 

[AlexMidd]

I agree Access is buggy, like most MS software, but it is a very useful and powerful tool if used properly. I have written large and robust applications in it. The beauty of it is it does not need as much learning as other apps (VB is a reasonably straight-forward language), the visual building of queries is top-notch (I usually use this to build SQL satements that I can use elsewhere and it works a dream), and it is excellent for RAD when users want a quick solution.

It's waht we call "swings and roundabouts" - what you get with other apps you lose the ease of development that Access has. I would say that, if you use Access, either accept the bugs or use the time you save to make your apps more robust (which you have to do with any programming interface, no matter how good it is).

Have fun! )

Alex Middleton