EXE from Access

  • Thread starter Thread starter H. Martins
  • Start date Start date
H

H. Martins

I have Access 2003 and Visual Studio 2005.

A couple years ago I suppose I have done some tests that resulted in
the conversion of Access program into an executable program.

I can't find out what I have done and I am nor sure about all this
matter.

Can I have some help, please?

H. Martins
 
There has never been a way to convert an Access application into an
executable in any version of Access.

You may have been trying one of the third-party products that purport to be
able to reverse engineer an Access application into Visual Basic. Tony Toews
lists some at http://www.granite.ab.ca/access/accesstovb.htm but the general
consensus is that they do an incomplete job at best.

Why do you feel it's necessary to have an executable?
 
Why do you feel it's necessary to have an executable?
Click to expand...

No. Could be some other way. I found out that MDE + install package
could be suitable solution. Still some people mention Visual Studio
some mention some extra Access Package as methods to get runtime
deployment package.

I can't clear out the right path. There are many Microsoft links
pointing to nowhere.

H. Martins
 
If you're looking for the runtime, Tony Toews attempts to demystify things
at http://www.granite.ab.ca/access/developereditionversions.htm

Just to be explicit, though, the runtime doesn't change your application in
any way, shape or form.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)


Why do you feel it's necessary to have an executable?
Click to expand...

No. Could be some other way. I found out that MDE + install package
could be suitable solution. Still some people mention Visual Studio
some mention some extra Access Package as methods to get runtime
deployment package.

I can't clear out the right path. There are many Microsoft links
pointing to nowhere.

H. Martins
 
If you could back away from the technical for the moment and tell us what
your objective is, perhaps we can offer some solutions. In other words, if
you can explain WHAT you want to do, we can suggest HOW you might do it.

Why do you feel it's necessary to have an executable?
Click to expand...

No. Could be some other way. I found out that MDE + install package
could be suitable solution. Still some people mention Visual Studio
some mention some extra Access Package as methods to get runtime
deployment package.

I can't clear out the right path. There are many Microsoft links
pointing to nowhere.

H. Martins
 
If you could back away from the technical for the moment and tell us what
your objective is, perhaps we can offer some solutions.  In other words, if
you can explain WHAT you want to do, we can suggest HOW you might do it.
Click to expand...

OK.

The basic idea is to generate the code to access the database (the
data itself is located in a separated mdb file) so that it can't be
modified and avoiding the installation of Access itself.

A standalone EXE would be perfect. A second solution could be the
arrangement of a folder containing the complete set of files needed to
run the application.

After the application is stabilized (the number of new requests
decrease) I will look after porting the data to SQL server and
eventually porting the code to adapt it to SQL server (not sure how
much is needed). I suppose MS SQL Express will be enough.

I was convinced that by also using Visual Studio 2005 the arrangement
of a solution avoiding the installation of Access would be available.

Thanks
H. Martins
 
H. Martins said:
OK.

The basic idea is to generate the code to access the database (the
data itself is located in a separated mdb file) so that it can't be
modified and avoiding the installation of Access itself.

A standalone EXE would be perfect. A second solution could be the
arrangement of a folder containing the complete set of files needed to
run the application.

After the application is stabilized (the number of new requests
decrease) I will look after porting the data to SQL server and
eventually porting the code to adapt it to SQL server (not sure how
much is needed). I suppose MS SQL Express will be enough.

I was convinced that by also using Visual Studio 2005 the arrangement
of a solution avoiding the installation of Access would be available.
Click to expand...

You could move to 2007 which includes the ability to generate a runtime
package at no cost.
Access does a lot of behind the scenes work that you will have to do front
of house if you switch.
 
The basic idea is to generate the code to access the database (the
data itself is located in a separated mdb file) so that it can't be
modified and avoiding the installation of Access itself.
Click to expand...

That could be done by providing the user with a .mde file (or .accde file if
you're using 2007) and a copy of the Runtime version of Access.
A standalone EXE would be perfect. A second solution could be the
arrangement of a folder containing the complete set of files needed to
run the application.
Click to expand...

If you're using Access to run the application, all you need is the mde file.
After the application is stabilized (the number of new requests
decrease) I will look after porting the data to SQL server and
eventually porting the code to adapt it to SQL server (not sure how
much is needed). I suppose MS SQL Express will be enough.
Click to expand...

A mde (or mdb) file can use either another .mdb file OR SQL/Server as a data
storage medium. They both work fine.
I was convinced that by also using Visual Studio 2005 the arrangement
of a solution avoiding the installation of Access would be available.
Click to expand...

Yes it would; I'd estimate that it would approximately triple the amount of
work you would need to do to build a comprable user interface in Access.
Access Forms and Reports provide a rich array of data-aware tools (such as
bound forms, just for starters) that you would need to manually replicate in
Visual Studio.

If you want to go that way, go right ahead... just be aware that you're
getting yourself in to a whole lot more work. And no, you cannot convert an
existing Access frontend into a VS project.
 
Yes it would; I'd estimate that it would approximately triple the amount of
work you would need to do to build a comprable user interface in Access.
Access Forms and Reports provide a rich array of data-aware tools (such as
bound forms, just for starters) that you would need to manually replicatein
Visual Studio.
Click to expand...

No, no. I meant that I thought that just by having Visual Studio
installed, some sort of plugins would be added to Acccess allowing it
to generate stand alone code. I think that it is what happens with
'Tools->User and Group Permissions'. As much as I remember this is a
Visual Studio add in to Access.

I had a try with Access 2007 but I gave up. The interface was hocus-
pucus.

Could I eventually use Access 2007 just as stand-alone application
generation tool while keep using 2003 as development tool (should I
have to port data format to 2007?)?

Still remember the horrific default form layout that Access 2007
offers.

Thanks for help,
H. Martins
 
H. Martins said:
No, no. I meant that I thought that just by having Visual Studio
installed, some sort of plugins would be added to Acccess allowing it
to generate stand alone code. I think that it is what happens with
'Tools->User and Group Permissions'. As much as I remember this is a
Visual Studio add in to Access.

I had a try with Access 2007 but I gave up. The interface was hocus-
pucus.

Could I eventually use Access 2007 just as stand-alone application
generation tool while keep using 2003 as development tool (should I
have to port data format to 2007?)?

Still remember the horrific default form layout that Access 2007
offers.

Thanks for help,
H. Martins
Click to expand...

The Interface is designed more for the end user than the professional
developer but once you get used to it most things go faster.

As for the default form layout, I have never used one other than as a
starting point for small forms but I think it's cleaner than any other
version.

You could use 2003 to develop but you would be giving up features in 2007
that are very nice.
The date picker saves a lot of time and coding but does not work with 2003
format data and "multivaled fields" can be very nice.
 
No, no. I meant that I thought that just by having Visual Studio
installed, some sort of plugins would be added to Acccess allowing it
to generate stand alone code. I think that it is what happens with
'Tools->User and Group Permissions'. As much as I remember this is a
Visual Studio add in to Access.
Click to expand...

That is not true and has never been true. The Runtime version of Access has at
times been made available as part of Visual Studio, but it is not now, and
never has been, possible to convert an Access database to executable code. And
Workgroup Security (user and group permissions) has nothing to do with Visual
Studio (and in fact has been REMOVED from 2007).
I had a try with Access 2007 but I gave up. The interface was hocus-
pucus.

Could I eventually use Access 2007 just as stand-alone application
generation tool while keep using 2003 as development tool (should I
have to port data format to 2007?)?
Click to expand...

2007 can use Access2002/3 format databases natively, no porting is necessary.
Still remember the horrific default form layout that Access 2007
offers.
Click to expand...

It's a *huge* change, and a lot of experienced Access developers are
struggling with it - myself among them! People new to Access apparently like
it better, though.
 
John said:
2007 can use Access2002/3 format databases natively, no porting is
necessary.
Click to expand...
Yes but trying to use the date picker with 2003 in '07 comes under the
heading of "interesting" and I suspect that there are other little problems.

I was happy to see multivalued fields and the manner in which they are
handled. But now I want related multi-valued fields.

I did steal the way they are presented and use that in a few reports.
 
And
Workgroup Security (user and group permissions) has nothing to do
with Visual Studio (and in fact has been REMOVED from 2007).
Click to expand...

WRONG WRONG WRONG WRONG.

User-level security has always been a feature of the underlying
database engine, not of Access, and it is the new database engine,
the ACE and its ACCEDB format that has no user-level security. MDB
files, which are a native format for Access 2007, and the file
format for Jet 4 and all previous versions of Jet (ACE = Jet 5 or
4.5 by a different name), have user-level security as a base
feature.

So when you're using an MDB in Access 2007, ULS is fully usable and
accessible, and this is entirely because Access 2007 is using the
compatibility mode of the ACE that is able to read and write data in
files in the formats of previous Jet versions.

Please don't say that A2K7 doesn't support ULS (or Replication, for
that matter), because IT DOES SUPPORT IT. It's only certain file
formats that lack support for it, not Access itself.
 
That could be done by providing the user with a .mde file (or
.accde file if you're using 2007) and a copy of the Runtime
version of Access.
Click to expand...

Well, except for the "avoiding the installation of Access itself."
The runtime *is* Access, just running in a different mode and with
different licensing.

If the concern is for the users to not have interactive Access
installed, then the runtime takes care of it.

If the concern is some weird desire to avoid having all those files
installed, then the runtime is not going to make it any better.
If you're using Access to run the application, all you need is the
mde file.
Click to expand...

Plus the runtime, of course.

[]
Yes it would; I'd estimate that it would approximately triple the
amount of work you would need to do to build a comprable user
interface in Access. Access Forms and Reports provide a rich array
of data-aware tools (such as bound forms, just for starters) that
you would need to manually replicate in Visual Studio.

If you want to go that way, go right ahead... just be aware that
you're getting yourself in to a whole lot more work. And no, you
cannot convert an existing Access frontend into a VS project.
Click to expand...

What is it with all these people who are averse to the runtime?
Where does that attitude come from? MichKa always used to say that
the workset for a VB app was actually as large or larger than the
equivalent Access app. I'd tend to believe him, and it's workset
that really matters once you're past the issue of how long it takes
to develop the damned thing.
 
John W. Vinson said:
The Runtime version of Access has at
times been made available as part of Visual Studio
Click to expand...

<nit pick> The ADE, or A2003 runtime, was only available as part of
Visual Studio Tools for Office. This is a totally different product
than Visual Studio. said:
2007 can use Access2002/3 format databases natively, no porting is necessary.
Click to expand...

And A2000 MDEs. With which I routinely test.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Linq said:
In keeping with John's comment about v2007

"a lot of experienced Access developers are struggling with it -
myself among them! People new to Access apparently like it better,
though"

someone I recognized as a very experienced developer who's been in
since the first version (sorry, I have a bad memory leak and can't
remember who) estimated that the differences between previous
versions and v2007 and were so great that the learning curve was
approximately three times as great for an experienced developer as it
was for a Access newbie!
Click to expand...

My fiirst "real" database was dBase II on the Osborne I.
Over the years I've switched a few times and the one trick I learned was to
stop doing things the way the last program did.
Both the new and the old start not knowing where to look for things, but the
old developer should have a better grasp of what group to look in.

On the other hand "three ties" is a bit nebulous and maybe it's three
seconds rather than one.

One thing I find more than thrre times slower on my system is help and for
VBA I've been using http://www.techonthenet.com/access/index.php rathre than
click on help and wait.
 
Mike Painter said:
One thing I find more than thrre times slower on my system is help and for
VBA I've been using http://www.techonthenet.com/access/index.php rathre than
click on help and wait.
Click to expand...

I still use A97 help.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
[nothing that was actually a followup to my post]

Why didn't you followup John's post instead of mine? The usual
courtesy in that is to explicitly say you're not responding to the
post you replied to, but are "piggybacking" on it to reply to
something it quoted.
 
<nit pick> The ADE, or A2003 runtime, was only available as part of
Visual Studio Tools for Office. This is a totally different


And A2000 MDEs. With which I routinely test.
Click to expand...

That is, of course, because all of them are Jet 4 MDBs, and that is
a native format for A2K7.
 
About the Access 2007 'new look' (not just default form format but IDE
itself - menus, etc), I also found it mysterious.

Indeed, I found out that some company was producing some sort of plug-
in to enable 2007 to display 2003 format menus. I didn't try.

I have nothing against the existence of MDE runtime companion files.
The problem is that the application must be installed in some portable
computers whose owners may not have Access and I don't want to get
involved in installing (or instructing them how) other than some
minimum software in their computers. Eventually, just copying a bunch
of files to some folder would be OK.

Anyway, looks like I will need Access 2007 just to generate MDE, I
should keep with 2003 file format to avoid the lack of User Level
Security and ... what else ...?

Would it be easier (while avoiding to find myself in a good position
do be target for side effects) if I get the Visual Studio Tools for
Office and keep using 2003?

Thanks
H. Martins
 
Back
Top