Is dotnet justified here??

[dgmoore]

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

[Michael Moreno]

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/

[Larry Lard]

dg*****@erols.c om 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
la*******@googl email.com
The address is real, but unread - please reply to the group
For VB and C# questions - tell us which version

[Kevin Spencer]

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.

<dg*****@erols. comwrote in message
news:11******** **************@ v45g2000cwv.goo glegroups.com.. .

>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

[dgmoore]

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.

<dg*****@erols. comwrote in message
news:11******** **************@ v45g2000cwv.goo glegroups.com.. .

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

[William Stacey [C# MVP]]

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]

<dg*****@erols. comwrote in message
news:11******** **************@ v45g2000cwv.goo glegroups.com.. .
|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
|

[Henry Jones]

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.
<dg*****@erols. comwrote in message
news:11******** **************@ 11g2000cwr.goog legroups.com...

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
extensibilit y, 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.

<dg*****@erols .comwrote in message
news:11******* *************** @v45g2000cwv.go oglegroups.com. ..

>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

[RobinS]

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

Robin S.
----------------------------------------
"Henry Jones" <he***@TheCheck IsInTheMail.com wrote in message
news:eT******** ******@TK2MSFTN GP03.phx.gbl...

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.
<dg*****@erols. comwrote in message
news:11******** **************@ 11g2000cwr.goog legroups.com...

>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
productivit y, 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.
Application s 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
technologie s 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.

<dg*****@erol s.comwrote in message
news:11****** *************** *@v45g2000cwv.g ooglegroups.com ...
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

[Kevin Spencer]

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.

<dg*****@erols. comwrote in message
news:11******** **************@ 11g2000cwr.goog legroups.com...

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
extensibilit y, 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.

<dg*****@erols .comwrote in message
news:11******* *************** @v45g2000cwv.go oglegroups.com. ..

>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