Visual Studio (Developers Edition) for 2000 Wanted

[Andi Plotsky]

I am not a .NET developer. I want the Developer's Edition of Visual Studio
for use with my Access2000 databases. Does anyone have a clue as to where
to find it - my office manager says only .NET is available from any websites
she's searched. Anybody have a used copy they'd like to get rid of?
Is/should it be impossible to get hold of this product? My understanding
is that .NET doesn't offer that much as far as Access development is
concerned, so it's not worth learning. Am I approaching this from the wrong
angle?

Thanks!

Andi
--
Andi Plotsky
IRIS, LLC
2859 Galahad Drive
Atlanta, GA 30345

404-321-9459 (office)
404-636-2331 (fax)
ir******@bellsouth.net

[Salad]

Andi Plotsky wrote:

I am not a .NET developer. I want the Developer's Edition of Visual Studio
for use with my Access2000 databases. Does anyone have a clue as to where
to find it - my office manager says only .NET is available from any websites
she's searched. Anybody have a used copy they'd like to get rid of?
Is/should it be impossible to get hold of this product? My understanding
is that .NET doesn't offer that much as far as Access development is
concerned, so it's not worth learning. Am I approaching this from the wrong
angle?

Thanks!

Andi

Have you gone to http://www.google.com and searched for Visual Studio 6?
You might consider doing your own research.

[Douglas J. Steele]

Are you sure it's Visual Studio you're looking for, and not Office
Developer? Office Developer is what gives you the royalty-free run-time
version of Access that you can package together with your application so
that users who don't have Access installed will still be able to use your
application.

In any case, Microsoft no longer sells either.

One possibility is to check out sites that specialize in old software
products, such as http://www.emsps.com/oldtools/ or
http://recycledsoftware.com/

Another is to look at someplace like eBay to see whether anyone's trying to
see their old versions (Note, though, that products purchased this way
aren't always legal...)
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:W5******************@bignews5.bellsouth.net.. .

I am not a .NET developer. I want the Developer's Edition of Visual Studio for use with my Access2000 databases. Does anyone have a clue as to where
to find it - my office manager says only .NET is available from any websites she's searched. Anybody have a used copy they'd like to get rid of?
Is/should it be impossible to get hold of this product? My understanding
is that .NET doesn't offer that much as far as Access development is
concerned, so it's not worth learning. Am I approaching this from the wrong angle?

Thanks!

Andi
--
Andi Plotsky
IRIS, LLC
2859 Galahad Drive
Atlanta, GA 30345

404-321-9459 (office)
404-636-2331 (fax)
ir******@bellsouth.net

[Andi Plotsky]

RE: Are you sure it's Visual Studio you're looking for, and not Office

Developer?
Hmmm....good question. Maybe I'm confused about the capabilities of each.
I want to be able to make .EXE files (and run-time, I guess?). My main
interest is in being able to give the database to a client and they can use
it fully, but without the capability of changing code or object structures.
It would be great if someone could use it without having Access, although my
clients are mainly university labs, and they would be likely to have the
program. But maybe it would help with problems re: version control.

With the run-time edition:
1) Can the user add/delete/edit records or only use a canned database
(such as a library catalog) which already has the records in it you will
want to use?
2) Can a run-time version be placed on a server for multiple users to
use (say, 1-6 users)?
3) Does the run-time edition use up more computer resources than an .MDE
file would?
4) Are there other issues I need to take into consideration regarding
use of run-time?

Thanks for your help, Doug.

Andi


"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:9P**********************@twister01.bloor.is.n et.cable.rogers.com... Are you sure it's Visual Studio you're looking for, and not Office
Developer? Office Developer is what gives you the royalty-free run-time
version of Access that you can package together with your application so
that users who don't have Access installed will still be able to use your
application.

In any case, Microsoft no longer sells either.

One possibility is to check out sites that specialize in old software
products, such as http://www.emsps.com/oldtools/ or
http://recycledsoftware.com/

Another is to look at someplace like eBay to see whether anyone's trying to see their old versions (Note, though, that products purchased this way
aren't always legal...)
--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:W5******************@bignews5.bellsouth.net.. .

I am not a .NET developer. I want the Developer's Edition of Visual

Studio

for use with my Access2000 databases. Does anyone have a clue as to where to find it - my office manager says only .NET is available from any

websites

she's searched. Anybody have a used copy they'd like to get rid of?
Is/should it be impossible to get hold of this product? My understanding is that .NET doesn't offer that much as far as Access development is
concerned, so it's not worth learning. Am I approaching this from the

wrong

angle?

Thanks!

Andi
--
Andi Plotsky
IRIS, LLC
2859 Galahad Drive
Atlanta, GA 30345

404-321-9459 (office)
404-636-2331 (fax)
ir******@bellsouth.net

[Douglas J. Steele]

Answers in-line below.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:oT*******************@bignews3.bellsouth.net. ..

RE: Are you sure it's Visual Studio you're looking for, and not Office

Developer?
Hmmm....good question. Maybe I'm confused about the capabilities of each.
I want to be able to make .EXE files (and run-time, I guess?).

Neither one's capable of converting your Access application into an EXE:
there's no product in existence that can do that.

Assuming you've already developed your application in Access, with Visual
Studio, you'd have to rewrite practically everything to Visual Basic or
Visual C++ (both of which can be compiled into an executable). However,
you'd still need the MDB to store your data.

WIth Office Developer, you'd be able to package your application (either an
MDB or MDE) together with the run-time. Users who don't have Access would
install the run-time along with your application in order to be able to use
it. This exercise does not change your application in any way, shape or
form.
My main
interest is in being able to give the database to a client and they can use it fully, but without the capability of changing code or object structures.

An MDE won't let them change code or object structures. However, you need
Access installed (either the full version or the run-time version) in order
to use an MDE.
It would be great if someone could use it without having Access, although my clients are mainly university labs, and they would be likely to have the
program. But maybe it would help with problems re: version control.

With the run-time edition:
1) Can the user add/delete/edit records or only use a canned database
(such as a library catalog) which already has the records in it you will
want to use?
Yes
2) Can a run-time version be placed on a server for multiple users to
use (say, 1-6 users)?
No. The runtime must be installed on their desktop.
3) Does the run-time edition use up more computer resources than an ..MDE file would?
Irrelevant question. The run-time is the executable that it used to run the
application, whether it's an MDB or MDE.
4) Are there other issues I need to take into consideration regarding
use of run-time?

Consider looking into a 3rd party product for packaging your application
together with the run-time so as to avoid problems with multiple OS. SageKey
at http://www.sagekey.com/ is one that's often recommended.

[Andi Plotsky]

Thank you SO MUCH, Doug. I think I've got it now (yes, an MDE is what I
meant - not .EXE - I understand the difference). Hi-ho, Hi- ho it's to
Office Developer I go :)

Thanks (I hope I can return the favor some day).

Andi
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:DT**********************@twister01.bloor.is.n et.cable.rogers.com...

Answers in-line below.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:oT*******************@bignews3.bellsouth.net. ..

RE: Are you sure it's Visual Studio you're looking for, and not Office

Developer?
Hmmm....good question. Maybe I'm confused about the capabilities of each. I want to be able to make .EXE files (and run-time, I guess?).

Neither one's capable of converting your Access application into an EXE:
there's no product in existence that can do that.

Assuming you've already developed your application in Access, with Visual
Studio, you'd have to rewrite practically everything to Visual Basic or
Visual C++ (both of which can be compiled into an executable). However,
you'd still need the MDB to store your data.

WIth Office Developer, you'd be able to package your application (either

an MDB or MDE) together with the run-time. Users who don't have Access would
install the run-time along with your application in order to be able to use it. This exercise does not change your application in any way, shape or
form.

My main
interest is in being able to give the database to a client and they can use

it fully, but without the capability of changing code or object

structures.

An MDE won't let them change code or object structures. However, you need
Access installed (either the full version or the run-time version) in

order to use an MDE.

It would be great if someone could use it without having Access, although

my

clients are mainly university labs, and they would be likely to have the
program. But maybe it would help with problems re: version control.

With the run-time edition:
1) Can the user add/delete/edit records or only use a canned

database (such as a library catalog) which already has the records in it you will
want to use?

Yes

2) Can a run-time version be placed on a server for multiple users to use (say, 1-6 users)?

No. The runtime must be installed on their desktop.

3) Does the run-time edition use up more computer resources than an

.MDE

file would?

Irrelevant question. The run-time is the executable that it used to run

the application, whether it's an MDB or MDE.

4) Are there other issues I need to take into consideration regarding use of run-time?
Consider looking into a 3rd party product for packaging your application
together with the run-time so as to avoid problems with multiple OS.

SageKey at http://www.sagekey.com/ is one that's often recommended.

[Larry Linson]

On the other hand, there is no Developer Edition for Office 2003 System.
Perhaps that is where some confusion lies... for Office 2003, the Access
runtime support is found in "Visual Studio.NET Tools for Office 2003
System". It also includes C# and VB.NET, which are now supported languages
for Excel and Word, but not yet for Access.

Larry Linson
Microsoft Access MVP

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:zc*******************@bignews2.bellsouth.net. ..

Thank you SO MUCH, Doug. I think I've got it now (yes, an MDE is what I
meant - not .EXE - I understand the difference). Hi-ho, Hi- ho it's to
Office Developer I go :)

Thanks (I hope I can return the favor some day).

Andi
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:DT**********************@twister01.bloor.is.n et.cable.rogers.com...

Answers in-line below.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:oT*******************@bignews3.bellsouth.net. ..

RE: Are you sure it's Visual Studio you're looking for, and not Office
> Developer?

Hmmm....good question. Maybe I'm confused about the capabilities of each. I want to be able to make .EXE files (and run-time, I guess?).

Neither one's capable of converting your Access application into an EXE:
there's no product in existence that can do that.

Assuming you've already developed your application in Access, with Visual

Studio, you'd have to rewrite practically everything to Visual Basic or
Visual C++ (both of which can be compiled into an executable). However,
you'd still need the MDB to store your data.

WIth Office Developer, you'd be able to package your application (either

an

MDB or MDE) together with the run-time. Users who don't have Access would install the run-time along with your application in order to be able to

use

it. This exercise does not change your application in any way, shape or
form.

My main
interest is in being able to give the database to a client and they can

use

it fully, but without the capability of changing code or object

structures.

An MDE won't let them change code or object structures. However, you need Access installed (either the full version or the run-time version) in

order

to use an MDE.

It would be great if someone could use it without having Access, although

my

clients are mainly university labs, and they would be likely to have

the program. But maybe it would help with problems re: version control.

With the run-time edition:
1) Can the user add/delete/edit records or only use a canned

database (such as a library catalog) which already has the records in it you will want to use?

Yes

2) Can a run-time version be placed on a server for multiple users to use (say, 1-6 users)?

No. The runtime must be installed on their desktop.

3) Does the run-time edition use up more computer resources than

an .MDE

file would?

Irrelevant question. The run-time is the executable that it used to run

the

application, whether it's an MDB or MDE.

4) Are there other issues I need to take into consideration

regarding use of run-time?

Consider looking into a 3rd party product for packaging your application
together with the run-time so as to avoid problems with multiple OS.

SageKey

at http://www.sagekey.com/ is one that's often recommended.

[Andi Plotsky]

Thanks for your reply, Larry -

I just want the Developer Edition 2000 (which I did find online today). I'm
not a .NET developer - maybe I will be one day, but I was just in the
throes of learning the old-fashioned way when .NET came out....then I read
articles saying that it really didn't do much as far as Access development
goes, so I made an "executive decision" to let my poor feeble brain learn
one thing pretty well before switching to another.

From your point-of-view are C# and VB.NET decidedly better/easier than my
plain vanilla method of developing databases (Access2000 w/ VBA)? I guess
another question would be CAN I develop the old-fashioned way using Visual
Studio.NET?

Andi
"Larry Linson" <bo*****@localhost.not> wrote in message
news:Aa********************@nwrddc01.gnilink.net.. .

On the other hand, there is no Developer Edition for Office 2003 System.
Perhaps that is where some confusion lies... for Office 2003, the Access
runtime support is found in "Visual Studio.NET Tools for Office 2003
System". It also includes C# and VB.NET, which are now supported languages
for Excel and Word, but not yet for Access.

Larry Linson
Microsoft Access MVP

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:zc*******************@bignews2.bellsouth.net. ..

Thank you SO MUCH, Doug. I think I've got it now (yes, an MDE is what I
meant - not .EXE - I understand the difference). Hi-ho, Hi- ho it's to
Office Developer I go :)

Thanks (I hope I can return the favor some day).

Andi
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message
news:DT**********************@twister01.bloor.is.n et.cable.rogers.com...

Answers in-line below.

--
Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(No private e-mails, please)

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:oT*******************@bignews3.bellsouth.net. ..
> RE: Are you sure it's Visual Studio you're looking for, and not Office > > Developer?
>
> Hmmm....good question. Maybe I'm confused about the capabilities of

each.

> I want to be able to make .EXE files (and run-time, I guess?).

Neither one's capable of converting your Access application into an EXE: there's no product in existence that can do that.

Assuming you've already developed your application in Access, with Visual Studio, you'd have to rewrite practically everything to Visual Basic or Visual C++ (both of which can be compiled into an executable). However, you'd still need the MDB to store your data.

WIth Office Developer, you'd be able to package your application (either

an

MDB or MDE) together with the run-time. Users who don't have Access would install the run-time along with your application in order to be able

to

use

it. This exercise does not change your application in any way, shape

or form.

> My main
> interest is in being able to give the database to a client and they

can use
> it fully, but without the capability of changing code or object
structures.

An MDE won't let them change code or object structures. However, you need Access installed (either the full version or the run-time version) in

order

to use an MDE.

> It would be great if someone could use it without having Access,

although

my
> clients are mainly university labs, and they would be likely to have the > program. But maybe it would help with problems re: version control.
>
> With the run-time edition:
> 1) Can the user add/delete/edit records or only use a canned

database

> (such as a library catalog) which already has the records in it you will > want to use?

Yes

> 2) Can a run-time version be placed on a server for multiple users to

> use (say, 1-6 users)?

No. The runtime must be installed on their desktop.

> 3) Does the run-time edition use up more computer resources than an .MDE
> file would?

Irrelevant question. The run-time is the executable that it used to

run the

application, whether it's an MDB or MDE.

> 4) Are there other issues I need to take into consideration

regarding

> use of run-time?

Consider looking into a 3rd party product for packaging your

application together with the run-time so as to avoid problems with multiple OS.

SageKey

at http://www.sagekey.com/ is one that's often recommended.

[Larry Linson]

No, the point I was making was NOT that .NET is preferrable. The point I was
making was that is the ONLY way to obtain the standard Access runtime
support for Access 2003. You cannot yet use either of those .NET languages
with Access, so that is not even an option.

Responsible Microsoft corporate officers have publicly stated that VBA will
be supported in the next version of Access. I suspect that VBA is likely to
be supported for additional versions after that, but have not seen any
published information to that effect. There are too many "legacy Access
applications" that depend on VBA -- and, I am certain that Microsoft knows
that dropping VBA would disturb a huge number of their customers.

Larry Linson
Microsoft Access MVP
"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:h4*******************@bignews4.bellsouth.net. ..

Thanks for your reply, Larry -

I just want the Developer Edition 2000 (which I did find online today). I'm not a .NET developer - maybe I will be one day, but I was just in the
throes of learning the old-fashioned way when .NET came out....then I read
articles saying that it really didn't do much as far as Access development
goes, so I made an "executive decision" to let my poor feeble brain learn
one thing pretty well before switching to another.

From your point-of-view are C# and VB.NET decidedly better/easier than my
plain vanilla method of developing databases (Access2000 w/ VBA)? I guess
another question would be CAN I develop the old-fashioned way using Visual
Studio.NET?

Andi
"Larry Linson" <bo*****@localhost.not> wrote in message
news:Aa********************@nwrddc01.gnilink.net.. .

On the other hand, there is no Developer Edition for Office 2003 System.
Perhaps that is where some confusion lies... for Office 2003, the Access
runtime support is found in "Visual Studio.NET Tools for Office 2003
System". It also includes C# and VB.NET, which are now supported languages

for Excel and Word, but not yet for Access.

Larry Linson
Microsoft Access MVP

"Andi Plotsky" <ir******@bellsouth.net> wrote in message
news:zc*******************@bignews2.bellsouth.net. ..

Thank you SO MUCH, Doug. I think I've got it now (yes, an MDE is what I meant - not .EXE - I understand the difference). Hi-ho, Hi- ho it's to Office Developer I go :)

Thanks (I hope I can return the favor some day).

Andi
"Douglas J. Steele" <NOSPAM_djsteele@NOSPAM_canada.com> wrote in message news:DT**********************@twister01.bloor.is.n et.cable.rogers.com... > Answers in-line below.
>
> --
> Doug Steele, Microsoft Access MVP
> http://I.Am/DougSteele
> (No private e-mails, please)
>
>
>
> "Andi Plotsky" <ir******@bellsouth.net> wrote in message
> news:oT*******************@bignews3.bellsouth.net. ..
> > RE: Are you sure it's Visual Studio you're looking for, and not Office > > > Developer?
> >
> > Hmmm....good question. Maybe I'm confused about the capabilities of each.
> > I want to be able to make .EXE files (and run-time, I guess?).
>
> Neither one's capable of converting your Access application into an EXE: > there's no product in existence that can do that.
>
> Assuming you've already developed your application in Access, with

Visual

> Studio, you'd have to rewrite practically everything to Visual Basic or > Visual C++ (both of which can be compiled into an executable). However, > you'd still need the MDB to store your data.
>
> WIth Office Developer, you'd be able to package your application (either an
> MDB or MDE) together with the run-time. Users who don't have Access

would

> install the run-time along with your application in order to be able to use
> it. This exercise does not change your application in any way, shape or > form.
>
> > My main
> > interest is in being able to give the database to a client and they can

> use
> > it fully, but without the capability of changing code or object
> structures.
>
> An MDE won't let them change code or object structures. However, you

need

> Access installed (either the full version or the run-time version)

in order
> to use an MDE.
>
> > It would be great if someone could use it without having Access,
although
> my
> > clients are mainly university labs, and they would be likely to have

the

> > program. But maybe it would help with problems re: version

control. > >
> > With the run-time edition:
> > 1) Can the user add/delete/edit records or only use a canned
database
> > (such as a library catalog) which already has the records in it

you will

> > want to use?
>
> Yes
>
> > 2) Can a run-time version be placed on a server for multiple users to
> > use (say, 1-6 users)?
>
> No. The runtime must be installed on their desktop.
>
> > 3) Does the run-time edition use up more computer resources

than an

> .MDE
> > file would?
>
> Irrelevant question. The run-time is the executable that it used to

run the
> application, whether it's an MDB or MDE.
>
> > 4) Are there other issues I need to take into consideration
regarding
> > use of run-time?
>
> Consider looking into a 3rd party product for packaging your application > together with the run-time so as to avoid problems with multiple OS.
SageKey
> at http://www.sagekey.com/ is one that's often recommended.
>
>

[Steve]

On Sat, 01 May 2004 19:40:46 GMT, "Larry Linson"
<bo*****@localhost.not> wrote:

<Snipped>

No, the point I was making was NOT that .NET is preferrable. The point I was
making was that is the ONLY way to obtain the standard Access runtime
support for Access 2003. You cannot yet use either of those .NET languages
with Access, so that is not even an option.
The only .net lanuage included in Visual Studio.NET Tools for Office
2003 is VB.Net. (not C# as stated in your previous post). See
http://msdn.microsoft.com/vstudio/office/default.aspx and read
carefully.

Responsible Microsoft corporate officers have publicly stated that VBA will
be supported in the next version of Access. I suspect that VBA is likely to
be supported for additional versions after that, but have not seen any
published information to that effect. There are too many "legacy Access
applications" that depend on VBA -- and, I am certain that Microsoft knows
that dropping VBA would disturb a huge number of their customers.

I agree with you for the next several years, but not for the
long-term. Microsoft did not decided to package the Access Developer
Extensions (e.g. run-time) with VB.Net and Microsof Visual Studio
Tools for no reason at all. Clearly, that want to expose VBAers to
Net.

And let's not forget that one can install Office without VBA now, but
still use .Net to write code for Excel and Word. So even if they keep
VBA in for "transition", one may be dealing with organizations that no
longer install VBA with office.

Regarding disturbing a huge number of their customers, look want they
did with VB. Ask a VBer about being "disturbed" with VB.Net.

Steven R. Zuch
Cogent Management Inc.

Micrsoft packaged the Access run-time with VB.Net, and

[Andi Plotsky]

No, it looks like it DOES have C#.NET:

Microsoft Visual Studio Tools for the Microsoft Office System:
"With this technology, developers using Visual Studio .NET 2003 can use
Microsoft Visual Basic .NET and Microsoft Visual C# .NET to write code
behind Word- and Excel-based applications. "

"Steve" <st***@nospam.com> wrote in message
news:40***************@news.westnet.com...

On Sat, 01 May 2004 19:40:46 GMT, "Larry Linson"
<bo*****@localhost.not> wrote:

<Snipped>

No, the point I was making was NOT that .NET is preferrable. The point I wasmaking was that is the ONLY way to obtain the standard Access runtime
support for Access 2003. You cannot yet use either of those .NET languageswith Access, so that is not even an option.

The only .net lanuage included in Visual Studio.NET Tools for Office
2003 is VB.Net. (not C# as stated in your previous post). See
http://msdn.microsoft.com/vstudio/office/default.aspx and read
carefully.

Responsible Microsoft corporate officers have publicly stated that VBA willbe supported in the next version of Access. I suspect that VBA is likely tobe supported for additional versions after that, but have not seen any
published information to that effect. There are too many "legacy Access
applications" that depend on VBA -- and, I am certain that Microsoft knowsthat dropping VBA would disturb a huge number of their customers.

I agree with you for the next several years, but not for the
long-term. Microsoft did not decided to package the Access Developer
Extensions (e.g. run-time) with VB.Net and Microsof Visual Studio
Tools for no reason at all. Clearly, that want to expose VBAers to
Net.

And let's not forget that one can install Office without VBA now, but
still use .Net to write code for Excel and Word. So even if they keep
VBA in for "transition", one may be dealing with organizations that no
longer install VBA with office.

Regarding disturbing a huge number of their customers, look want they
did with VB. Ask a VBer about being "disturbed" with VB.Net.

Steven R. Zuch
Cogent Management Inc.

Micrsoft packaged the Access run-time with VB.Net, and

[Larry Linson]

"Steve" wrote

Regarding disturbing a huge number of
their customers, look want they did with
VB. Ask a VBer about being "disturbed"
with VB.Net.

It is certainly true that there were quite a few VBers who were disturbed by
the change to VB.NET with no backward compatibility. However, Microsoft
quite correctly judged that they could get by with _pushing developers
around_. Most of the upset VBers with whom I am acquainted have "gotten over
it" and are now doing VB.NET. A large number of those who are _not_, just
switched from VB to C#, so are still in the ".NET fold". They simply
realized that, unless they wanted to make the _major_ change of switching
_platforms_, they had no choice but to go along. A miniscule percentage
actually did switch platforms -- and some were surprised at the learning
curve they had to negotiate.

On the other hand, the number of Office users dwarfs the number of VB
developers (3 million or so, according to Microsoft, I think), and they
won't be "pushing individual developers around" but trying to push around
corporate clients (many of whom are already disgusted with being pushed
around... re: .NET and significant licensing changes that cost them a great
deal). The April 26 issue of one of the trade magazine eWeek had a featured
story about the evaluation by several companies of Office 2003 versus
OpenOffice.

Many of those enterprise customers are _always_ evaluating the benefits of
conversion to Linux, or commercial Unix, or whatever might be more
cost-effective in the long run. I think Microsoft is too smart to keep
heaping fuel on a fire that might burn them. It was when IBM, as a whole,
got so arrogant as to disregard the fact that their customers had other
alternatives that they almost went under; I believe Microsoft's leadership
is smart enough to learn from history rather than face repeating it. I hope
they prove me right. <GRIN>

Larry Linson
Microsoft Access MVP

[Steve]

On Sat, 1 May 2004 18:49:15 -0400, "Andi Plotsky"
<ir******@bellsouth.net> wrote:

No, it looks like it DOES have C#.NET:

Microsoft Visual Studio Tools for the Microsoft Office System:
"With this technology, developers using Visual Studio .NET 2003 can use
Microsoft Visual Basic .NET and Microsoft Visual C# .NET to write code
behind Word- and Excel-based applications. "

No, it does NOT include C#. Just because the Tools give you the
ability to interface C# with Office, does not mean that the Tools
INCLUDE the development language! You need, as CLEARLY stated above,
VIsual Studio .NET 2003, which is a seperate and distinct package from
Visual Studio Tools.

If you go to the link that I already provided, you will see exactly
what the Tools include, and what it does not. It does include VB.Net,
as the link explicity states.

Steven
"Steve" <st***@nospam.com> wrote in message
news:40***************@news.westnet.com...

On Sat, 01 May 2004 19:40:46 GMT, "Larry Linson"
<bo*****@localhost.not> wrote:

<Snipped>

>No, the point I was making was NOT that .NET is preferrable. The point Iwas >making was that is the ONLY way to obtain the standard Access runtime
>support for Access 2003. You cannot yet use either of those .NETlanguages >with Access, so that is not even an option.

The only .net lanuage included in Visual Studio.NET Tools for Office
2003 is VB.Net. (not C# as stated in your previous post). See
http://msdn.microsoft.com/vstudio/office/default.aspx and read
carefully.

>
>Responsible Microsoft corporate officers have publicly stated that VBAwill >be supported in the next version of Access. I suspect that VBA is likelyto >be supported for additional versions after that, but have not seen any
>published information to that effect. There are too many "legacy Access
>applications" that depend on VBA -- and, I am certain that Microsoftknows >that dropping VBA would disturb a huge number of their customers.

I agree with you for the next several years, but not for the
long-term. Microsoft did not decided to package the Access Developer
Extensions (e.g. run-time) with VB.Net and Microsof Visual Studio
Tools for no reason at all. Clearly, that want to expose VBAers to
Net.

And let's not forget that one can install Office without VBA now, but
still use .Net to write code for Excel and Word. So even if they keep
VBA in for "transition", one may be dealing with organizations that no
longer install VBA with office.

Regarding disturbing a huge number of their customers, look want they
did with VB. Ask a VBer about being "disturbed" with VB.Net.

Steven R. Zuch
Cogent Management Inc.

Micrsoft packaged the Access run-time with VB.Net, and

[Steve]

On Sun, 02 May 2004 02:39:00 GMT, "Larry Linson"
<bo*****@localhost.not> wrote:

You really think that Microsoft will not continue the trend of
integrating .NET with Office? You really think that some version of
VB.Net will not become the standard macro language for Office?

Let's not forget that before VBA, Excel had a completely different
macro language than it has now.

Let's not forget that :

(1) Microsoft already allows Office to be installed without VBA, and

(2) Micorosft is providing tools to allow .Net coders to write for
Excel and Word, and

(3) Microsoft is making a strong effort to expose Access developers to
VB.Net by packaging it with the developer kit.

Yea, for the next couple of years VBA will be the Office language of
choice. But anyone getting involved in Office development, for the
long-term, better learn .Net.

It is certainly true that there were quite a few VBers who were disturbed by
the change to VB.NET with no backward compatibility. However, Microsoft
quite correctly judged that they could get by with _pushing developers
around_.
<SNIP>
On the other hand, the number of Office users dwarfs the number of VB
developers (3 million or so, according to Microsoft, I think), and they
won't be "pushing individual developers around" but trying to push around
corporate clients (many of whom are already disgusted with being pushed
around... re: .NET and significant licensing changes that cost them a great
deal).

Are you implying that VBers are individual developers, while Office is
used by corporate clients, and that Microsof may be less likely to
push the alrady disgusted corporate clients ????????

<SNIP>

Steven

[Andi Plotsky]

RE: I hope they prove me right. <GRIN>

Amen!!

"Larry Linson" <bo*****@localhost.not> wrote in message
news:8b*******************@nwrddc03.gnilink.net...

"Steve" wrote

> Regarding disturbing a huge number of
> their customers, look want they did with
> VB. Ask a VBer about being "disturbed"
> with VB.Net.
It is certainly true that there were quite a few VBers who were disturbed

by the change to VB.NET with no backward compatibility. However, Microsoft
quite correctly judged that they could get by with _pushing developers
around_. Most of the upset VBers with whom I am acquainted have "gotten over it" and are now doing VB.NET. A large number of those who are _not_, just
switched from VB to C#, so are still in the ".NET fold". They simply
realized that, unless they wanted to make the _major_ change of switching
_platforms_, they had no choice but to go along. A miniscule percentage
actually did switch platforms -- and some were surprised at the learning
curve they had to negotiate.

On the other hand, the number of Office users dwarfs the number of VB
developers (3 million or so, according to Microsoft, I think), and they
won't be "pushing individual developers around" but trying to push around
corporate clients (many of whom are already disgusted with being pushed
around... re: .NET and significant licensing changes that cost them a great deal). The April 26 issue of one of the trade magazine eWeek had a featured story about the evaluation by several companies of Office 2003 versus
OpenOffice.

Many of those enterprise customers are _always_ evaluating the benefits of
conversion to Linux, or commercial Unix, or whatever might be more
cost-effective in the long run. I think Microsoft is too smart to keep
heaping fuel on a fire that might burn them. It was when IBM, as a whole,
got so arrogant as to disregard the fact that their customers had other
alternatives that they almost went under; I believe Microsoft's leadership
is smart enough to learn from history rather than face repeating it. I hope they prove me right. <GRIN>

Larry Linson
Microsoft Access MVP

[Larry Linson]

"Steve" wrote

You really think that Microsoft will not
continue the trend of integrating .NET
with Office?
I really think I said nothing of the kind, Steve, only that VBA would be
supported for a longer time than many expect.
You really think that some version of
VB.Net will not become the standard
macro language for Office?
I really think that, if/when Microsoft _replaces_ VBA with VB.NET (or other
object-oriented .NET languages), they will lose a goodly number of their
Access power users and non-professional programmer-developers. It galls me
to see the issue approached from a point of view that assumes all users of
code-behind-forms are "professional programmer" developers; we are, in fact,
a minority of the users.

..NET development is for developers; Office development, including VBA, has
addressed a much larger audience.
Are you implying that VBers are
individual developers, while Office is
used by corporate clients, and that
Microsof may be less likely to push
the alrady disgusted corporate clients ????????

I am not implying, but stating (read carefully, as you seem not to be doing,
Steve) that the _disgruntled_ VB developers I know were individual,
independent developers. The employee-corporate-developers I knew didn't
really much care -- they knew their employers would provide them the
necessary education, absorb the necessary performance hits and compensate by
investing in faster hardware (e.g., for Windows apps), etc. and that they
wouldn't be blamed.

If I were Microsoft, I'd be very, very careful about pushing corporate
clients who are already on-edge over the issues I mentioned. Whether
Microsoft actually will be, I can't say. Back when the licensing flap was at
its peak, I read at least one editorial in a trade magazine (with far more
extensive corporate contacts than I have) that said in boardrooms all over
the world, the word went down the chain of command to the IT departments to
"get them out of our computer rooms, NOW", and only after the IT managers
explained how difficult it would be to do that immediately did they relent.
I do know that there is a long memory in the corporate boardrooms about
vendors they believe tried to take advantage of them, and, they may have
simply moderated that order to "as soon as possible", or just be waiting for
what they perceive as yet another misstep.

Larry Linson

[James Fortune]

"Larry Linson" <bo*****@localhost.not> wrote in message news:<8b*******************@nwrddc03.gnilink.net>. ..

"Steve" wrote

> Regarding disturbing a huge number of
> their customers, look want they did with
> VB. Ask a VBer about being "disturbed"
> with VB.Net.
It is certainly true that there were quite a few VBers who were disturbed by
the change to VB.NET with no backward compatibility. However, Microsoft
quite correctly judged that they could get by with _pushing developers
around_. Most of the upset VBers with whom I am acquainted have "gotten over
it" and are now doing VB.NET. A large number of those who are _not_, just
switched from VB to C#, so are still in the ".NET fold". They simply
realized that, unless they wanted to make the _major_ change of switching
_platforms_, they had no choice but to go along. A miniscule percentage
actually did switch platforms -- and some were surprised at the learning
curve they had to negotiate.

On the other hand, the number of Office users dwarfs the number of VB
developers (3 million or so, according to Microsoft, I think), and they
won't be "pushing individual developers around" but trying to push around
corporate clients (many of whom are already disgusted with being pushed
around... re: .NET and significant licensing changes that cost them a great
deal). The April 26 issue of one of the trade magazine eWeek had a featured
story about the evaluation by several companies of Office 2003 versus
OpenOffice.

If your miniscule percentage is universal then MS has nothing to worry
about, right? For those companies that are already running dual
platforms the learning curve is not nearly so steep, yet just as
rewarding. I did a large project using ASP so a shift to VB.NET
should be a no-brainer, but I still want to compare the amount of
development time using VB.NET with that of using MySQL and PHP. The
clients will see all the pros and cons and have a good idea about the
costs beforehand. If the VBers that work for enterprise clients have
really "gotten over it" then MS has nothing to worry about, right?
The huge licensing costs of SQL Server definitely played a role for
them in considering other alternatives.
Many of those enterprise customers are _always_ evaluating the benefits of
conversion to Linux, or commercial Unix, or whatever might be more
cost-effective in the long run. I think Microsoft is too smart to keep
heaping fuel on a fire that might burn them. It was when IBM, as a whole,
got so arrogant as to disregard the fact that their customers had other
alternatives that they almost went under; I believe Microsoft's leadership
is smart enough to learn from history rather than face repeating it. I hope
they prove me right. <GRIN>
My clients will probably be about 75% MS, 25% Linux/UNIX within a
year. Those percentages will likely remain steady for several years
unless Microsoft does something to alienate them. If MS really does
save more money then they'll gladly embrace the 800 lb gorilla, er..
bad analogy :-). My clients love Access and would love it if MS turns
out to be more cost effective. In the mean time they will be able to
compare NT Server with Linux/UNIX and Office with OpenOffice side by
side. In the past, MS cashed in on the observation that companies take
the easy way out about 99% of the time. Now, companies are starting
to evaluate the increasing costs associated with taking the easy way
out. Either way, MS and Linux/UNIX OS's will both be around to
provide their unique advantages for the foreseeable future, at least
around here.

Larry Linson
Microsoft Access MVP

James A. Fortune

[Larry Linson]

"Jerry Linson" wrote

Kinda hypocritical doncha think?

Funny, Don P, very funny that you, of all people, should think you can get
away with claiming anyone else is hypocritical.

By the way, even when you use that alias so close to my name, people know
you are not me, so my credibility here doesn't accrue to your benefit.
<SIGH> I bet it seemed like _such_ a good idea at the time.