Office XP Developer 1

[Jeradatar]

I have XP Developer and desperately need to create and Access executable file ASAP. I have paged thru all the manuals and can find no reference to it. I was assured by the vendor that I purchased the product from that I would be able to do this (they confirmed with Microsoft).
Anyway anyone out there have any quick tips? Some step I might be missing?
Any Help would be greatly appreciated.

 

[ggreg]

In VB under File there is a
Make project 1.exe.....how about looking
there for yours under File?
hopes this helps

 

[Jeradatar]

ggreg
The Make line is greyed out when I open the VB window, I have the Database open in Access an select the open VB option. I'm obviously missing something

 

[ggreg]

Jeradatar,

I was not suggesting that you make it with vb...my thought
was that if it is done like that in VB then maybe they do it
the
same way in XP Developer so open Xp Developer open the
database that you want to make exe then click on file
in Xp Developer and see if make becomes active.
sorry for the confusion.
Greg

 

[thornmastr]

Neither you, God, nor Bill Gates can produce an executable out of an mdb file. Sorry. If some salesman told you it would happen because you have the developer’s edition….he lied. The developers edition will allow you to change your mdb file to an mde file which is your database without code and which will not let your users modify your forms, modules, querires etc. To create an MDE while in Access using your mdb, click tools>database utilities > make MDE.

Now, if “make MDB is grayed out” it is because you are using A2k file format and you have A2k2, so you will have to change your database format to A2k2. tools>options>advanced.

Now that you have a mde file you are going to need the Access run time libraries to make it work on PC’s without Access.. You do the start>programs>Microsoft office XP Developer>Packaging wizard. Now all you have to do is get that correct, burn a CD, find a virgin machine to test your install; and this, my friend, is as close to an exe as you will ever get using Access; and no, you cannot convert an mde into a VB program without a heck of a lot of work.

Of course, if you have not created your own menu bars and swichboards, you won't like your MDE very much anyway.

Personally, I think you ought to kick the salesman.

Good luck.

Robert Berman
Data Base consultant
Vulcan Software Services
thornmastr@yahoo.com

 

[Quehay]

This might be a good time to ask: Does anyone work with Access runtime apps and recommend doing so? I'd like to be able to distribute without worrying about the Office Professional existence, but I suspect that these things are very problematic (Access runtimes)--they're probably even more problematic if you hope to have the Windows Installer do a remote install for you... Jeff Roberts
Analysis, Design, & Implementation
RenaissanceData.com

 

[number2]

I am currently distributing an application which was developed in Access and using the Packaging wizard. (why?...1) because my market is small with only 1000 or so possible buyers 2) I can not code VB well enough to write the app soley in VB)

Here are some of the issues I have run into and overcome (for the most part)
1) The Accees Packager which installs runtime, system files, your database file and your supporting files creates a HUGE setup directory. In my case it is over 180Mb. For too large to be downloadable. This is a distibution problem. I must distribute soley via CDROM.

2) .MDE files CAN NOT save PRINTER SETUP information. This is problematic if you wish to make use of "specific printers" or paper sizes etc. In my case, I wanted to enable a dedicated label printer, however iin the .MDE version this was rendered impossible as the user could not select their label printer and SAVE that information. They would need to re-select the printer EACH time they printed, along with making paper, margin settings. This works fine in a .MBD file, however if you distribute in a .MDB file your code and design will be exposed to design changes, both planned, unplanned or malicious.

3) XP Runtime setup WILL NOT run on Win95. I believe this is a system file problem, in my tests on 2 diferent Win95 machines, the install failed to complete.

4) XP Runtime may ask to restart the users PC 2 or more times on installing. This can scare some users, so make sure you inform them that this is normal. How many restarts depends on which is OS running.

5) There is NO SPELL CHECKER build into Access Runtime. If you need a spell checker in your application, you will need to purchase a 3rd party spell checker or pay MS a huge per issue royalty for their spell checker.

6) TEST TEST TEST! This is a huge install. This makes testing difficult and time consuming. When you think the install is stable, check it again. Also, the install options are a bit cryptic and limited. For instance, the setup routine will not even allow for a desktop icon. It does however create a Start Menu Icon.

These are some of the major obsticles I encountered. I feel that Access Runtime and the Packaging Wizard does a fair job. You can create usable applications with limited budgets. However, for larger deployments and smaller more stable code, VB is probably a better choice. (see my reasons for going with Access above)

 

[petermeachem]

I found out why it's such a huge install. It's because our chums at Microsoft have bunged in a copy of IE. Nice.

They have 'addressed the issue' after 'some representations' ! and there is a much smaller install now.

I wouldn't dream of using Access to sell something to 1000 users. It's just brilliant in one office, anything more than a few people, I'd use Vb every time.

Quote from another thread.


I just read this on

http://www.larkfarm.com/sax/sax11.txt

Thought it was relevant.


---------------------------------------------------------
3) ACCESS RUN-TIME MINIMUM RELEASED
---------------------------------------------------------
Perhaps you're among the developers who've been
frustrated by the fact that the Access 2000 Run-Time
takes 150MB to install---not counting your own database!
One of the culprits in that bloat is the "hidden"
installation of Internet Explorer 5.0 that comes along
with every runtime application.

Well, Microsoft has addressed this problem to some extent
with the new Access Run-Time Minimum; you can grab it at

http://support.microsoft.com/support/kb/articles/Q243/9/57.ASP.

This version leaves out all but the essential IE5 files,
with the result that it weighs in at a relatively svelte
70MB.

It's a sobering thought that the "minimum" size of
anything can be larger than the combined disk space on
the first four PCs that I owned, but I guess that just
shows my advancing age.
Peter Meachem
peter@accuflight.com

 

[Quehay]

Why does the "Oh yes, and we included a 5 lb bag of dog food even though you asked for a tuna sandwich" approach from Microsoft not surprise me...

Thanks for the useful info guys. I think I'll have to invest in a NET upgrade for any distributed apps (or get smart and switch to Delphi). Of course with VB you lose the power of Access reporting (the "what's left out" side of MS). Jeff Roberts
Analysis, Design, & Implementation
RenaissanceData.com

 

[number2]

The problem with the "minimun install of runtime" is that there is the requirement that IE already needs to be installed on the users PC. If they do not have it they must get it...so if you don't want headaches, you are stuck with the bloated full install.

 

[petermeachem]

What is annoying is that Access obviously does not want IE, completely different thing. What is does want is some versions of files that IE comes with, so MS take the easy way and install IE. Also helps to mop up that extra 5% of people who don't use IE I suppose. Peter Meachem
peter@accuflight.com

 

[Craig0201]

Peter,

Actually Access may need IE. IE is installed as some of it's components are used by MDAC. And without MDAC, you get will have more difficulty making ODBC calls.

Craig

 

[DonQuichote]

Say what? You need an internet browser to access a database? If the runtime version of Access needs MDAC, it should install MDAC, not IE5.

 

[petermeachem]

mdac is what 7Mb or so. IE is much much bigger. Peter Meachem
peter@accuflight.com

 

[Rhonin]

To one and all,
Anyway you cut it, MSAccess app only if they have office installed. Anything else do it in VB.
Where are the good old days when size was a SERIOUS issue?
Oh well...

For number2... in your mde have you files use a system default printer, not a specified type.

Rhonin
"too many questions, too little time..."

 

[Zeroanarchy]

Thought I would add my peice of info relating to runtime.

1. I have been using run time for considerable time and currently produce programs for corporations and Government departments. I surgest using runtime over VB where there will be less than 15users at one time as I have seen to many compatatability probs with VB apps when a users upgrades their Windows version were as runtime relies on internal files and is a lot less likely to have error on the user.

2. I suggest against using the runtime wizard to distribute your app as it is quite restrictave and you are also taking legal responsability for any programming errors Microsoft have made instead create a VB setup app that requires very little outside files and really just copies the files to the relevant location.

thanks petermeachem for you reference to the downsizing of runtime very handy to know.

 

[number2]

To Rhonin: re: the printer set up issue; not all users have the same label printer at the same location. You can get away with the default printer setting for normal page printing, however if youo need to specify an additional, or secondary printer (ie. label printer) you are stuck. There is no way for the end user to save the setting.

Can someone give an outline of which files need be included for a "bare bones" VD based Access Runtime setup routine?

I would like to restate that for small deployments, where money for development is a great issue, Access Runtime can get the job done. Even if the end user does not have Office installed. It would be noce however to see MS tighten up some of the issue raised here.
1)Smaller installation
2).mde printer setup saving
3)spell check inclusion
4)retool the packager to include better customization

As far as accepting responsability for the runtime installation, I don't see this as an issue, as MS has certainly expounded the fact that Access Runtime CAN be used to distibute an Access Database to those who currently do not have Access installed on their PC. Therefore, MS is ultimately responsible to the installation of a well licensed Runtime. Morally, and ethically however, the distributor of any Runtime application should test and understand the Runtime installation, its strengths and weaknesses. In my testing, runtime can be uninstalled successdully and is resonably stable. If I could afford the expense of a re-write in VB I would do so, however cost/return dicatates in my particular instance.