|
|
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?
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no e-mails, please!)
"H. Martins" <HJRMartins[ at ]gmail.com> wrote in message
news:9c75076e-de61-4a8d-b0e4-ddc9531c6027[ at ]q26g2000prq.googlegroups.com...
[Quoted Text] >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
|
|
On Nov 11, 12:24 pm, "Douglas J. Steele"
<NOSPAM_djsteele[ at ]NOSPAM_gmail.com> wrote:
[Quoted Text] > 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
|
|
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
http://I.Am/DougSteele
(no e-mails, please!)
"H. Martins" <HJRMartins[ at ]gmail.com> wrote in message
news:bbe7d49e-33f1-4b8d-ba8c-12b3ce9815fa[ at ]r37g2000prr.googlegroups.com...
On Nov 11, 12:24 pm, "Douglas J. Steele"
<NOSPAM_djsteele[ at ]NOSPAM_gmail.com> wrote:
[Quoted Text] > 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
|
|
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.
"H. Martins" <HJRMartins[ at ]gmail.com> wrote in message
news:bbe7d49e-33f1-4b8d-ba8c-12b3ce9815fa[ at ]r37g2000prr.googlegroups.com...
On Nov 11, 12:24 pm, "Douglas J. Steele"
<NOSPAM_djsteele[ at ]NOSPAM_gmail.com> wrote:
[Quoted Text] > 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
|
|
On Nov 11, 2:27 pm, "Klatuu" <david.har...[ at ]realpage.com> wrote:
[Quoted Text] > 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
|
|
H. Martins wrote:
[Quoted Text] > On Nov 11, 2:27 pm, "Klatuu" <david.har...[ at ]realpage.com> wrote:
>> 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.
>
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.
|
|
On Thu, 13 Nov 2008 10:08:48 -0800 (PST), "H. Martins" <HJRMartins[ at ]gmail.com>
wrote:
[Quoted Text] >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.
--
John W. Vinson [MVP]
|
|
On Nov 13, 8:59 pm, John W. Vinson
<jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote:
[Quoted Text] > 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.
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 wrote:
[Quoted Text] > On Nov 13, 8:59 pm, John W. Vinson
> <jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote:
>
>> 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.
>
> 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.
|
|
On Fri, 14 Nov 2008 01:07:47 -0800 (PST), "H. Martins" <HJRMartins[ at ]gmail.com>
wrote:
[Quoted Text] >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.
--
John W. Vinson [MVP]
|
|
John W. Vinson wrote:
[Quoted Text] >>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.
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
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/200811/1
|
|
John W. Vinson wrote:
>
[Quoted Text] > 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.
|
|
John W. Vinson <jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote in
news:d4erh4du0dhnfd98md5fraujkm866b10os[ at ]4ax.com:
[Quoted Text] > 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 http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
John W. Vinson <jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote in
news:b35ph4hdorhhguvtmqetr5pa6s6hrm7mvf[ at ]4ax.com:
[Quoted Text] > On Thu, 13 Nov 2008 10:08:48 -0800 (PST), "H. Martins"
> <HJRMartins[ at ]gmail.com> wrote:
>
>>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.
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.
>>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.
Plus the runtime, of course.
[]
>>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.
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.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
John W. Vinson <jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote:
[Quoted Text] >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
than Visual Studio. </nit pick>
>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/
|
|
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!
--
There's ALWAYS more than one way to skin a cat!
Answers/posts based on Access 2000/2003
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/200811/1
|
|
Linq Adams via AccessMonster.com wrote:
[Quoted Text] > 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.
|
|
"Mike Painter" <mddotpainter[ at ]sbcglobal.net> wrote:
[Quoted Text]
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/
|
|
"Linq Adams via AccessMonster.com" <u28780[ at ]uwe> wrote in
news:8d4b310fb3cc4[ at ]uwe:
[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.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"Tony Toews [MVP]" <ttoews[ at ]telusplanet.net> wrote in
news:g3u0i4hr7akpcmb1pvge4u2gskkff4n4t3[ at ]4ax.com:
[Quoted Text] > John W. Vinson <jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote:
>
>>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 than Visual Studio. </nit pick>
>
>>2007 can use Access2002/3 format databases natively, no porting is
>>necessary.
>
> And A2000 MDEs. With which I routinely test.
That is, of course, because all of them are Jet 4 MDBs, and that is
a native format for A2K7.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
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
|
|
"H. Martins" <HJRMartins[ at ]gmail.com> wrote in
news:0d477133-b8d8-4907-8262-7684c198116b[ at ]q26g2000prq.googlegroups.co
m:
[Quoted Text] > I have nothing against the existence of MDE runtime companion
> files.
I don't understand that sentence. The MDE is your application file.
There are no companion files, or MDEs that are "companions" to your
app (unless you're using external libraries in MDE format, I guess).
> 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.
Well, if that's what you want, then you've chosen the wrong
development platform. The runtime + your application MDE is what you
need, but it has to be installed. There is no other way for an
Access app to work. Period. End of statement.
> 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 ...?
Even if you're running the A2K7 runtime, you don't need A2K7 to
generate the MDE. And MDB is not "2003 file format," but Jet 4
format, which is a native format for A2K7.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
[Quoted Text] > > I have nothing against the existence of MDE runtime companion
> > files.
>
> I don't understand that sentence. The MDE is your application file.
> There are no companion files, or MDEs that are "companions" to your
> app (unless you're using external libraries in MDE format, I guess).
>
As much as I understood, I can't run a MDE (or MDB) without Access
being installed in the computer.
If I want to avoid having Access installed I must generate an Access
Runtime packge, where MDE is included. The files installed by the
runtime package are what I call the companion files.
H. Martins
|
|
"H. Martins" <HJRMartins[ at ]gmail.com> wrote in
news:a164c2fb-16ef-47af-96b1-5dc525c61dd6[ at ]a3g2000prm.googlegroups.com
:
[Quoted Text] >
>> > I have nothing against the existence of MDE runtime companion
>> > files.
>>
>> I don't understand that sentence. The MDE is your application
>> file. There are no companion files, or MDEs that are "companions"
>> to your app (unless you're using external libraries in MDE
>> format, I guess).
>>
>
> As much as I understood, I can't run a MDE (or MDB) without Access
> being installed in the computer.
Yes, of course.
> If I want to avoid having Access installed I must generate an
> Access Runtime packge,
The Runtime *is* Access. So, the earlier statement applies:
You can't run an MDB/MDE without having Access installed. Period.
End of statement.
> where MDE is included.
The MDE will not be part of your runtime installation, but part of
your installer package.
> The files installed by the
> runtime package are what I call the companion files.
They aren't companion files -- they are ACCESS.
The point of the runtime is to be able to distribute an Access
application without the users having to buy a full license to
Access. But it is *still* Access that the runtime installs, just one
with different licensing.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|