I have a MSAccess utility application that pulls data from a SQL Server
database, manipulates it via VBA and sends it to MSProject to generate
Gantt charts, and produces imagemapped html pages to present the
charts.

This app runs unattended on a server as a scheduled task in the middle
of the night. The output is a large number of static web pages that are
updated daily. The application has been working problem-free for years,
and fully meets all user requirements.

A group of IT managers has announced that "all applications" serving
the project in question will be converted to .net.

I am not a .net expert, but I do not see any advantage to making this
app .net compliant. Can anybody suggest to me, in a general sense, how
the expense to do this conversion would be justified? Performance is
not an issue - the process takes about an hour to run and runs at night
when the network is idle, and the application is not required to
support user interaction.

Thanks
Dave

> I am not a .net expert, but I do not see any advantage to making this
> app .net compliant. Can anybody suggest to me, in a general sense, how
> the expense to do this conversion would be justified? Performance is

Quite simple to me:
- VB 6 is no longer supported by MS
- Very shortly it will be easier to find a .Net developper than a VB 6
one

--
Michael
----
http://michael.moreno.free.fr/
http://port.cogolin.free.fr/

(E-Mail Removed) wrote:
> I have a MSAccess utility application that pulls data from a SQL Server
> database, manipulates it via VBA and sends it to MSProject to generate
> Gantt charts, and produces imagemapped html pages to present the
> charts.
>
> This app runs unattended on a server as a scheduled task in the middle
> of the night. The output is a large number of static web pages that are
> updated daily. The application has been working problem-free for years,
> and fully meets all user requirements.
>
> A group of IT managers has announced that "all applications" serving
> the project in question will be converted to .net.
>
> I am not a .net expert, but I do not see any advantage to making this
> app .net compliant. Can anybody suggest to me, in a general sense, how
> the expense to do this conversion would be justified? Performance is
> not an issue - the process takes about an hour to run and runs at night
> when the network is idle, and the application is not required to
> support user interaction.

Unfortunately this isn't really a technical issue. You sound like the
kind of chap who to whom it won't be news that you can use any technical
approach to solve any problem - all that changes is the amount of pain.
Here, I think what you need to ask yourself is "How much pain will
pushing back against this group of IT managers cause" vs "How much pain
will rewriting in something .NETty bring". And the former depends on
political and social factors which only you will know about.

And as for expense - well, if someone tells you to do something, it's
*their* job to justify the expense, wouldn't you say?

--
Larry Lard
(E-Mail Removed)
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version

Hi Dave,

I feel your pain. However, a little bit of pain in the short run can save
you a lot in the long run. I'm not sure exactly what you mean by "a MSAcess
utility application," but I'm going to guess it's contained in an Access
database in one or more VBA Modules. There are a couple of problems with
this scenario that could eventually bite you.

First, VBA is not object-oriented. This doesn't sound like much of a
drawback until you factor in the evolution factor. That is, it is almost
always a given that any type of application is going to be modified,
extended, added to, have new features built in, etc. Because VBA is not
object-oriented, encapsulation is not really available to you. And the
larger an application becomes, the more important it becomes to encapsulate
code, to manage the availability of data and process in various parts of the
application. Object-oriented programming supplies this.

Second, you need to think about the entire lifetime of the application, and
plan for the future. Not only will VBA not be supported for much longer, but
there is an emerging set of .Net Platform tools for Office that provide
productivity, most likely much better productivity than you have now using
VBA. In addition, more and more of the Microsoft programming platform is
moving into the .Net arena, so .Net programming has legs. Microsoft Vista is
the next generation of Operating System from Microsoft, and it is not an
easy platform to write to, especially using legacy code. Applications will
no longer have the free reign of the OS that they have enjoyed until now;
the OS is much more secure. This means that your tool set will have to have
built-in support for the environment.

It's not a matter of being ".Net compliant," but embracing the
well-established .Net platform which Microsoft has specifically designed for
extensibility, something which traditional VBA was definitely not designed
for. In the same way that traditional HTML became increasingly complex and
unweildy, and is being replaced with extensible technologies, so has
Microsoft created an extensible, object-oriented programming technology to
replace the much less extensible and adaptable programming technologies that
have existed for decades.

Every once in awhile, as time goes by, it is a good idea to rework your
software "from the ground up" so to speak, in order to keep up with the
technology. Even Microsoft has had to do this, most recently with the .Net
platform itself, which is already 5 years old, and with the Vista operating
system. Ours is a business in which the technology is changing at a dizzying
rate, and faster each year than the year before it. It's difficult to keep
up, but the alternative is much worse.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

In case of Minimalism, break Philip Glass.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have a MSAccess utility application that pulls data from a SQL Server
> database, manipulates it via VBA and sends it to MSProject to generate
> Gantt charts, and produces imagemapped html pages to present the
> charts.
>
> This app runs unattended on a server as a scheduled task in the middle
> of the night. The output is a large number of static web pages that are
> updated daily. The application has been working problem-free for years,
> and fully meets all user requirements.
>
> A group of IT managers has announced that "all applications" serving
> the project in question will be converted to .net.
>
> I am not a .net expert, but I do not see any advantage to making this
> app .net compliant. Can anybody suggest to me, in a general sense, how
> the expense to do this conversion would be justified? Performance is
> not an issue - the process takes about an hour to run and runs at night
> when the network is idle, and the application is not required to
> support user interaction.
>
> Thanks
> Dave
>

Thanks, Kevin -

If you were in my shoes (advanced VBA/MSAccess/MSProject app developer
with zero knowledge of .Net), where would you start looking for info on
how to proceed?

Dave


Kevin Spencer wrote:
> Hi Dave,
>
> I feel your pain. However, a little bit of pain in the short run can save
> you a lot in the long run. I'm not sure exactly what you mean by "a MSAcess
> utility application," but I'm going to guess it's contained in an Access
> database in one or more VBA Modules. There are a couple of problems with
> this scenario that could eventually bite you.
>
> First, VBA is not object-oriented. This doesn't sound like much of a
> drawback until you factor in the evolution factor. That is, it is almost
> always a given that any type of application is going to be modified,
> extended, added to, have new features built in, etc. Because VBA is not
> object-oriented, encapsulation is not really available to you. And the
> larger an application becomes, the more important it becomes to encapsulate
> code, to manage the availability of data and process in various parts of the
> application. Object-oriented programming supplies this.
>
> Second, you need to think about the entire lifetime of the application, and
> plan for the future. Not only will VBA not be supported for much longer, but
> there is an emerging set of .Net Platform tools for Office that provide
> productivity, most likely much better productivity than you have now using
> VBA. In addition, more and more of the Microsoft programming platform is
> moving into the .Net arena, so .Net programming has legs. Microsoft Vista is
> the next generation of Operating System from Microsoft, and it is not an
> easy platform to write to, especially using legacy code. Applications will
> no longer have the free reign of the OS that they have enjoyed until now;
> the OS is much more secure. This means that your tool set will have to have
> built-in support for the environment.
>
> It's not a matter of being ".Net compliant," but embracing the
> well-established .Net platform which Microsoft has specifically designed for
> extensibility, something which traditional VBA was definitely not designed
> for. In the same way that traditional HTML became increasingly complex and
> unweildy, and is being replaced with extensible technologies, so has
> Microsoft created an extensible, object-oriented programming technology to
> replace the much less extensible and adaptable programming technologies that
> have existed for decades.
>
> Every once in awhile, as time goes by, it is a good idea to rework your
> software "from the ground up" so to speak, in order to keep up with the
> technology. Even Microsoft has had to do this, most recently with the .Net
> platform itself, which is already 5 years old, and with the Vista operating
> system. Ours is a business in which the technology is changing at a dizzying
> rate, and faster each year than the year before it. It's difficult to keep
> up, but the alternative is much worse.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Software Composer
> http://unclechutney.blogspot.com
>
> In case of Minimalism, break Philip Glass.
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >I have a MSAccess utility application that pulls data from a SQL Server
> > database, manipulates it via VBA and sends it to MSProject to generate
> > Gantt charts, and produces imagemapped html pages to present the
> > charts.
> >
> > This app runs unattended on a server as a scheduled task in the middle
> > of the night. The output is a large number of static web pages that are
> > updated daily. The application has been working problem-free for years,
> > and fully meets all user requirements.
> >
> > A group of IT managers has announced that "all applications" serving
> > the project in question will be converted to .net.
> >
> > I am not a .net expert, but I do not see any advantage to making this
> > app .net compliant. Can anybody suggest to me, in a general sense, how
> > the expense to do this conversion would be justified? Performance is
> > not an issue - the process takes about an hour to run and runs at night
> > when the network is idle, and the application is not required to
> > support user interaction.
> >
> > Thanks
> > Dave
> >

The best way to proceed is to get a beginners book on VB.NET, get the
software on your computer either at home or at work (if you can spend time
learning at work) and start doing the examples in the book. Pretty soon you
will pick up the differences between what you know and .NET. Then get a
good book on ADO.NET because it is different that what you have been using
now.

Since you work for the company that wants to move to the new technology,
have them pay for some .NET classes for you. That would even help more.

Hope this helps a bit.


<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks, Kevin -
>
> If you were in my shoes (advanced VBA/MSAccess/MSProject app developer
> with zero knowledge of .Net), where would you start looking for info on
> how to proceed?
>
> Dave
>
>
> Kevin Spencer wrote:
>> Hi Dave,
>>
>> I feel your pain. However, a little bit of pain in the short run can save
>> you a lot in the long run. I'm not sure exactly what you mean by "a
>> MSAcess
>> utility application," but I'm going to guess it's contained in an Access
>> database in one or more VBA Modules. There are a couple of problems with
>> this scenario that could eventually bite you.
>>
>> First, VBA is not object-oriented. This doesn't sound like much of a
>> drawback until you factor in the evolution factor. That is, it is almost
>> always a given that any type of application is going to be modified,
>> extended, added to, have new features built in, etc. Because VBA is not
>> object-oriented, encapsulation is not really available to you. And the
>> larger an application becomes, the more important it becomes to
>> encapsulate
>> code, to manage the availability of data and process in various parts of
>> the
>> application. Object-oriented programming supplies this.
>>
>> Second, you need to think about the entire lifetime of the application,
>> and
>> plan for the future. Not only will VBA not be supported for much longer,
>> but
>> there is an emerging set of .Net Platform tools for Office that provide
>> productivity, most likely much better productivity than you have now
>> using
>> VBA. In addition, more and more of the Microsoft programming platform is
>> moving into the .Net arena, so .Net programming has legs. Microsoft Vista
>> is
>> the next generation of Operating System from Microsoft, and it is not an
>> easy platform to write to, especially using legacy code. Applications
>> will
>> no longer have the free reign of the OS that they have enjoyed until now;
>> the OS is much more secure. This means that your tool set will have to
>> have
>> built-in support for the environment.
>>
>> It's not a matter of being ".Net compliant," but embracing the
>> well-established .Net platform which Microsoft has specifically designed
>> for
>> extensibility, something which traditional VBA was definitely not
>> designed
>> for. In the same way that traditional HTML became increasingly complex
>> and
>> unweildy, and is being replaced with extensible technologies, so has
>> Microsoft created an extensible, object-oriented programming technology
>> to
>> replace the much less extensible and adaptable programming technologies
>> that
>> have existed for decades.
>>
>> Every once in awhile, as time goes by, it is a good idea to rework your
>> software "from the ground up" so to speak, in order to keep up with the
>> technology. Even Microsoft has had to do this, most recently with the
>> .Net
>> platform itself, which is already 5 years old, and with the Vista
>> operating
>> system. Ours is a business in which the technology is changing at a
>> dizzying
>> rate, and faster each year than the year before it. It's difficult to
>> keep
>> up, but the alternative is much worse.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> Software Composer
>> http://unclechutney.blogspot.com
>>
>> In case of Minimalism, break Philip Glass.
>>
>> <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> >I have a MSAccess utility application that pulls data from a SQL Server
>> > database, manipulates it via VBA and sends it to MSProject to generate
>> > Gantt charts, and produces imagemapped html pages to present the
>> > charts.
>> >
>> > This app runs unattended on a server as a scheduled task in the middle
>> > of the night. The output is a large number of static web pages that are
>> > updated daily. The application has been working problem-free for years,
>> > and fully meets all user requirements.
>> >
>> > A group of IT managers has announced that "all applications" serving
>> > the project in question will be converted to .net.
>> >
>> > I am not a .net expert, but I do not see any advantage to making this
>> > app .net compliant. Can anybody suggest to me, in a general sense, how
>> > the expense to do this conversion would be justified? Performance is
>> > not an issue - the process takes about an hour to run and runs at night
>> > when the network is idle, and the application is not required to
>> > support user interaction.
>> >
>> > Thanks
>> > Dave
>> >
>

It is hard to say because we don't know what their long term plan is. On
the one hand, they could have accessed all their assets and want all these
1-offs converted into something they are investing in (i.e. .Net) As an
previous enterprise admin, these 1-offs can keep you up at night, especially
if only 1 or 2 people know anything about them. So that can make a lot of
sense from a on-going maintaince perspective even if it cost some money now.
They could want to clean-up. I could also more easier all integration into
operations dashboards, etc. Who knows. From your perspective, it should
not matter that much. You get a chance to do more work and learn .Net at
same time - a win-win for you I would think.

--
William Stacey [C# MVP]

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
|I have a MSAccess utility application that pulls data from a SQL Server
| database, manipulates it via VBA and sends it to MSProject to generate
| Gantt charts, and produces imagemapped html pages to present the
| charts.
|
| This app runs unattended on a server as a scheduled task in the middle
| of the night. The output is a large number of static web pages that are
| updated daily. The application has been working problem-free for years,
| and fully meets all user requirements.
|
| A group of IT managers has announced that "all applications" serving
| the project in question will be converted to .net.
|
| I am not a .net expert, but I do not see any advantage to making this
| app .net compliant. Can anybody suggest to me, in a general sense, how
| the expense to do this conversion would be justified? Performance is
| not an issue - the process takes about an hour to run and runs at night
| when the network is idle, and the application is not required to
| support user interaction.
|
| Thanks
| Dave
|

If you want a good ADO.Net book, check out Dave Sceppa's ADO.Net
Core Reference.

Robin S.
----------------------------------------
"Henry Jones" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> The best way to proceed is to get a beginners book on VB.NET, get the
> software on your computer either at home or at work (if you can spend
> time learning at work) and start doing the examples in the book.
> Pretty soon you will pick up the differences between what you know and
> .NET. Then get a good book on ADO.NET because it is different that
> what you have been using now.
>
> Since you work for the company that wants to move to the new
> technology, have them pay for some .NET classes for you. That would
> even help more.
>
> Hope this helps a bit.
>
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Thanks, Kevin -
>>
>> If you were in my shoes (advanced VBA/MSAccess/MSProject app
>> developer
>> with zero knowledge of .Net), where would you start looking for info
>> on
>> how to proceed?
>>
>> Dave
>>
>>
>> Kevin Spencer wrote:
>>> Hi Dave,
>>>
>>> I feel your pain. However, a little bit of pain in the short run can
>>> save
>>> you a lot in the long run. I'm not sure exactly what you mean by "a
>>> MSAcess
>>> utility application," but I'm going to guess it's contained in an
>>> Access
>>> database in one or more VBA Modules. There are a couple of problems
>>> with
>>> this scenario that could eventually bite you.
>>>
>>> First, VBA is not object-oriented. This doesn't sound like much of a
>>> drawback until you factor in the evolution factor. That is, it is
>>> almost
>>> always a given that any type of application is going to be modified,
>>> extended, added to, have new features built in, etc. Because VBA is
>>> not
>>> object-oriented, encapsulation is not really available to you. And
>>> the
>>> larger an application becomes, the more important it becomes to
>>> encapsulate
>>> code, to manage the availability of data and process in various
>>> parts of the
>>> application. Object-oriented programming supplies this.
>>>
>>> Second, you need to think about the entire lifetime of the
>>> application, and
>>> plan for the future. Not only will VBA not be supported for much
>>> longer, but
>>> there is an emerging set of .Net Platform tools for Office that
>>> provide
>>> productivity, most likely much better productivity than you have now
>>> using
>>> VBA. In addition, more and more of the Microsoft programming
>>> platform is
>>> moving into the .Net arena, so .Net programming has legs. Microsoft
>>> Vista is
>>> the next generation of Operating System from Microsoft, and it is
>>> not an
>>> easy platform to write to, especially using legacy code.
>>> Applications will
>>> no longer have the free reign of the OS that they have enjoyed until
>>> now;
>>> the OS is much more secure. This means that your tool set will have
>>> to have
>>> built-in support for the environment.
>>>
>>> It's not a matter of being ".Net compliant," but embracing the
>>> well-established .Net platform which Microsoft has specifically
>>> designed for
>>> extensibility, something which traditional VBA was definitely not
>>> designed
>>> for. In the same way that traditional HTML became increasingly
>>> complex and
>>> unweildy, and is being replaced with extensible technologies, so has
>>> Microsoft created an extensible, object-oriented programming
>>> technology to
>>> replace the much less extensible and adaptable programming
>>> technologies that
>>> have existed for decades.
>>>
>>> Every once in awhile, as time goes by, it is a good idea to rework
>>> your
>>> software "from the ground up" so to speak, in order to keep up with
>>> the
>>> technology. Even Microsoft has had to do this, most recently with
>>> the .Net
>>> platform itself, which is already 5 years old, and with the Vista
>>> operating
>>> system. Ours is a business in which the technology is changing at a
>>> dizzying
>>> rate, and faster each year than the year before it. It's difficult
>>> to keep
>>> up, but the alternative is much worse.
>>>
>>> --
>>> HTH,
>>>
>>> Kevin Spencer
>>> Microsoft MVP
>>> Software Composer
>>> http://unclechutney.blogspot.com
>>>
>>> In case of Minimalism, break Philip Glass.
>>>
>>> <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>> >I have a MSAccess utility application that pulls data from a SQL
>>> >Server
>>> > database, manipulates it via VBA and sends it to MSProject to
>>> > generate
>>> > Gantt charts, and produces imagemapped html pages to present the
>>> > charts.
>>> >
>>> > This app runs unattended on a server as a scheduled task in the
>>> > middle
>>> > of the night. The output is a large number of static web pages
>>> > that are
>>> > updated daily. The application has been working problem-free for
>>> > years,
>>> > and fully meets all user requirements.
>>> >
>>> > A group of IT managers has announced that "all applications"
>>> > serving
>>> > the project in question will be converted to .net.
>>> >
>>> > I am not a .net expert, but I do not see any advantage to making
>>> > this
>>> > app .net compliant. Can anybody suggest to me, in a general sense,
>>> > how
>>> > the expense to do this conversion would be justified? Performance
>>> > is
>>> > not an issue - the process takes about an hour to run and runs at
>>> > night
>>> > when the network is idle, and the application is not required to
>>> > support user interaction.
>>> >
>>> > Thanks
>>> > Dave
>>> >
>>
>
>

Hi Dave,

Along with the recommendations of the other people, who have directed you to
a couple of books on VB.Net development (a good start), let me direct you to
some online resources that should be very helpful:

Microsoft Developer Network (MSDN) (tons of resources of all kinds,
including free downloads)
http://msdn2.microsoft.com/en-us/default.aspx

MSDN Library
http://msdn2.microsoft.com/en-us/library/default.aspx

Microsoft Visual Basic Developer Center
http://msdn2.microsoft.com/en-us/vbasic/default.aspx

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer
http://unclechutney.blogspot.com

In case of Minimalism, break Philip Glass.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks, Kevin -
>
> If you were in my shoes (advanced VBA/MSAccess/MSProject app developer
> with zero knowledge of .Net), where would you start looking for info on
> how to proceed?
>
> Dave
>
>
> Kevin Spencer wrote:
>> Hi Dave,
>>
>> I feel your pain. However, a little bit of pain in the short run can save
>> you a lot in the long run. I'm not sure exactly what you mean by "a
>> MSAcess
>> utility application," but I'm going to guess it's contained in an Access
>> database in one or more VBA Modules. There are a couple of problems with
>> this scenario that could eventually bite you.
>>
>> First, VBA is not object-oriented. This doesn't sound like much of a
>> drawback until you factor in the evolution factor. That is, it is almost
>> always a given that any type of application is going to be modified,
>> extended, added to, have new features built in, etc. Because VBA is not
>> object-oriented, encapsulation is not really available to you. And the
>> larger an application becomes, the more important it becomes to
>> encapsulate
>> code, to manage the availability of data and process in various parts of
>> the
>> application. Object-oriented programming supplies this.
>>
>> Second, you need to think about the entire lifetime of the application,
>> and
>> plan for the future. Not only will VBA not be supported for much longer,
>> but
>> there is an emerging set of .Net Platform tools for Office that provide
>> productivity, most likely much better productivity than you have now
>> using
>> VBA. In addition, more and more of the Microsoft programming platform is
>> moving into the .Net arena, so .Net programming has legs. Microsoft Vista
>> is
>> the next generation of Operating System from Microsoft, and it is not an
>> easy platform to write to, especially using legacy code. Applications
>> will
>> no longer have the free reign of the OS that they have enjoyed until now;
>> the OS is much more secure. This means that your tool set will have to
>> have
>> built-in support for the environment.
>>
>> It's not a matter of being ".Net compliant," but embracing the
>> well-established .Net platform which Microsoft has specifically designed
>> for
>> extensibility, something which traditional VBA was definitely not
>> designed
>> for. In the same way that traditional HTML became increasingly complex
>> and
>> unweildy, and is being replaced with extensible technologies, so has
>> Microsoft created an extensible, object-oriented programming technology
>> to
>> replace the much less extensible and adaptable programming technologies
>> that
>> have existed for decades.
>>
>> Every once in awhile, as time goes by, it is a good idea to rework your
>> software "from the ground up" so to speak, in order to keep up with the
>> technology. Even Microsoft has had to do this, most recently with the
>> .Net
>> platform itself, which is already 5 years old, and with the Vista
>> operating
>> system. Ours is a business in which the technology is changing at a
>> dizzying
>> rate, and faster each year than the year before it. It's difficult to
>> keep
>> up, but the alternative is much worse.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> Software Composer
>> http://unclechutney.blogspot.com
>>
>> In case of Minimalism, break Philip Glass.
>>
>> <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> >I have a MSAccess utility application that pulls data from a SQL Server
>> > database, manipulates it via VBA and sends it to MSProject to generate
>> > Gantt charts, and produces imagemapped html pages to present the
>> > charts.
>> >
>> > This app runs unattended on a server as a scheduled task in the middle
>> > of the night. The output is a large number of static web pages that are
>> > updated daily. The application has been working problem-free for years,
>> > and fully meets all user requirements.
>> >
>> > A group of IT managers has announced that "all applications" serving
>> > the project in question will be converted to .net.
>> >
>> > I am not a .net expert, but I do not see any advantage to making this
>> > app .net compliant. Can anybody suggest to me, in a general sense, how
>> > the expense to do this conversion would be justified? Performance is
>> > not an issue - the process takes about an hour to run and runs at night
>> > when the network is idle, and the application is not required to
>> > support user interaction.
>> >
>> > Thanks
>> > Dave
>> >
>