EXE from Access

[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

 

[Douglas J. Steele]

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?

 

[H. Martins]

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

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

 

[Douglas J. Steele]

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?

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

 

[Klatuu]

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?

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

 

[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.

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

 

[Mike Painter]

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.

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.

 

[John W. Vinson]

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.

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.

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.

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.

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.

 

[H. Martins]

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.

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

 

[Mike Painter]

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

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.

 

[John W. Vinson]

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.

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?)?

2007 can use Access2002/3 format databases natively, no porting is necessary.

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

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.

 

[Cyberwolf0000 via AccessMonster.com]

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).


2007 can use Access2002/3 format databases natively, no porting is necessary.


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.

I too find Acc07 to be confusing. I have been an avid Access user since
Acc97 and really enjoy the many features that come natively with it. I
recently tried using a copy of 2007 and got very frustrated just trying to do
simple things that I could do in seconds in earlier versions. I know there
are some nice new features in 2007, but am reluctant to switch becuase of
what i feel will be a high learning curve just to get acquainted to 2007.

--
James B Gaylord
For the Wolf comes the strength of the Pack,
For the Pack comes the strength of the Wolf,
-R. Kipling
Office 2003 on Win XP SP2

 

[Mike Painter]

2007 can use Access2002/3 format databases natively, no porting is
necessary.

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.

 

[David W. Fenton]

And
Workgroup Security (user and group permissions) has nothing to do
with Visual Studio (and in fact has been REMOVED from 2007).

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.

 

[David W. Fenton]

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.

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.

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.

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.

 

[Tony Toews [MVP]]

The Runtime version of Access has at
times been made available as part of Visual Studio

<nit pick> The ADE, or A2003 runtime, was only available as part of
Visual Studio Tools for Office. This is a totally different product

2007 can use Access2002/3 format databases natively, no porting is necessary.

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 Adams via AccessMonster.com]

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!

 

[Mike Painter]

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!

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.

 

[Tony Toews [MVP]]

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.

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/

 

[David W. Fenton]

[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.