By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,027 Members | 1,111 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,027 IT Pros & Developers. It's quick & easy.

SQL, XML, and ASP.NET: Upgrading from a client-side heavy classic ASP app

P: n/a
Hi,

We have a major ASP app that we are in the process of upgrading to
ASP.NET 1.1 and probably on to ASP.NET 2.0 in the middle of next year.
(We will also be upgrading to SQL2K5 at the same time).

The current architecture is heavily based on the client side, both for
validation and data access. The asp page is returned and then data is
modified or selected using XMLHTTP objects embedded on the page, which
post or get to a data enabled virtual directory. Within this we use a
multitude of different SQL XML techniques including updategrams, XML
Views, XML Templates and straight http queries. There is a little bit
of ADO access.

At the moment, upgrading a page to ASP.NET simply means separating off
the server side code to code behind (which is easy due to decent asp
page formatting) and strongly typing all the variables (and a few other
bits and pieces). The major benefit of this is the ease of debugging in
ASP.NET as opposed to the hideousness of debugging ASP. However it
still leaves all the data access on the client side and essentially
leaves us with legacy code that is still heavily client based. Because
we have not done much with the ASP.NET, developers are still creating
new pages by copying and altering existing ASP pages. I have been asked
to come up with some recommendations on what to do. I'm not talking
unlimited budget, but this app will be our major solution for the next
5 years so we need to get it into a decent state that can be supported
and can utilise the benefits of asp.net. It may be that we need a
different upgrade route for existing pages and for creating new pages.
Atthe moment we're sort of stuck halfway between the 2 technologies.

I'm afraid that while I can code an ASP.NET website, I am no expert.
I'm very much a SQL Server guy. So I would appreciate any advice that
anyone can give or pointers to good articles. What is the general
consensus on using data enabled virtual directories from an app? How
hard would it be, and would it be worth the effort, to recode to use
ADO.NET or SQLXML managed classes and scrap the data enabled virtual
directory?

Sorry if I'm asking the wrong questions. The current architecture is so
antithetical to ASP.NET that it's difficult to see what can be done.
Beyond recommending that we immediately do the basic conversion of all
ASP pages to ASP.NET, I'm a bit stumped. It seems like it would be a
major project to make any kind of changes at all. Advice please!

Cheers,

James

Oct 16 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"JimLad" <ja*********@yahoo.co.ukwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Because we have not done much with the ASP.NET, developers are still
creating
new pages by copying and altering existing ASP pages.
Firstly, IMO that is almost the worst approach you could take

ASP and ASP.NET are so COMPLETELY different because of the .NET Framework
that, in my experience, doing it this way virtually never works, and will
give you huge problems in the long run.

You need to stop your devlopers immediately and design a new architecture
based around ASP.NET and the .NET Framework. Analyse your current business
requirements, not those that you had when your ASP Classic web app was first
designed. If they haven't changed much since then, you can use your existing
web app as a prototype, but no more than that.
I have been asked to come up with some recommendations on what to do.
I'm not talking unlimited budget, but this app will be our major solution
for the
next 5 years so we need to get it into a decent state that can be
supported
and can utilise the benefits of asp.net. It may be that we need a
different upgrade route for existing pages and for creating new pages.
Atthe moment we're sort of stuck halfway between the 2 technologies.
You've hit the nail on the head there.
I'm afraid that while I can code an ASP.NET website, I am no expert.
I'm very much a SQL Server guy. So I would appreciate any advice that
anyone can give or pointers to good articles. What is the general
consensus on using data enabled virtual directories from an app? How
hard would it be, and would it be worth the effort, to recode to use
ADO.NET or SQLXML managed classes and scrap the data enabled virtual
directory?
It wouldn't be that hard. I would strongly recommend the following:

1) make the leap to SQL Server 2005 now - there simply is no point in
waiting any longer.

2) look at the new schema model in SQL Server 2005 and adopt that rather
than several databases

3) go straight to ASP.NET 2 - as with SQL Server, there simply is no merit
in not using the current version, especially as you're looking at a
long-term investment - 5 years is a huge amount of time in computing... :-)

4) use a database abstraction layer (DAL) to interface with SQL Server - use
Microsoft's "best practice" example as a starting point:
http://aspnet.4guysfromrolla.com/articles/070203-1.aspx

5) in addition to the DAL, create as many base classes as you feel are
necessary to your business model e.g. for encryption, validation, email,
registry etc

Your email address suggests you're based in the UK - I've done upwards of 20
..NET / .NET2 upgrades and can help you further with this - please contact me
directly for more information.
Oct 16 '06 #2

P: n/a
First bit of advice: go directly to 2.0. No reason to bite the bullet twice.

I would also aim at figuring out the use cases (how the site is actually
used) before coding anything. You have the potential of working one use case
at a time and having temporary co-existence of ASP and ASP.NET, but it si
best to isolate usage first so you have a clean path. Page by page does not
normally work in this way, because ASP architecture has functionality spread
across multiple pages.

Aim for writing a new application rather than a rewrite. Fix the annoyances
as you "upgrade". While this may seem obvious, I have seen many managers who
assume it is "just an upgrade" when, in reality, it is a new application.
Only by keeping this in the forefront will you keep your sanity. :-)

I would also consider writing in C#. While you do not leverage your VBScript
to VB.NET skills, you will be less likely to bring VB baggage along for the
ride. It is easier to make a paradigm change with a language change than
without.

MSDN has some articles on upgrading from classic ASP to ASP.NET.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************************************************
Think outside of the box!
*************************************************
"JimLad" <ja*********@yahoo.co.ukwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Hi,

We have a major ASP app that we are in the process of upgrading to
ASP.NET 1.1 and probably on to ASP.NET 2.0 in the middle of next year.
(We will also be upgrading to SQL2K5 at the same time).

The current architecture is heavily based on the client side, both for
validation and data access. The asp page is returned and then data is
modified or selected using XMLHTTP objects embedded on the page, which
post or get to a data enabled virtual directory. Within this we use a
multitude of different SQL XML techniques including updategrams, XML
Views, XML Templates and straight http queries. There is a little bit
of ADO access.

At the moment, upgrading a page to ASP.NET simply means separating off
the server side code to code behind (which is easy due to decent asp
page formatting) and strongly typing all the variables (and a few other
bits and pieces). The major benefit of this is the ease of debugging in
ASP.NET as opposed to the hideousness of debugging ASP. However it
still leaves all the data access on the client side and essentially
leaves us with legacy code that is still heavily client based. Because
we have not done much with the ASP.NET, developers are still creating
new pages by copying and altering existing ASP pages. I have been asked
to come up with some recommendations on what to do. I'm not talking
unlimited budget, but this app will be our major solution for the next
5 years so we need to get it into a decent state that can be supported
and can utilise the benefits of asp.net. It may be that we need a
different upgrade route for existing pages and for creating new pages.
Atthe moment we're sort of stuck halfway between the 2 technologies.

I'm afraid that while I can code an ASP.NET website, I am no expert.
I'm very much a SQL Server guy. So I would appreciate any advice that
anyone can give or pointers to good articles. What is the general
consensus on using data enabled virtual directories from an app? How
hard would it be, and would it be worth the effort, to recode to use
ADO.NET or SQLXML managed classes and scrap the data enabled virtual
directory?

Sorry if I'm asking the wrong questions. The current architecture is so
antithetical to ASP.NET that it's difficult to see what can be done.
Beyond recommending that we immediately do the basic conversion of all
ASP pages to ASP.NET, I'm a bit stumped. It seems like it would be a
major project to make any kind of changes at all. Advice please!

Cheers,

James

Oct 16 '06 #3

P: n/a
you should look at the atlas library for .net (beta avaiable now). it uses
xmphttp under the covers, but will give you a supported library.

-- bruce (sqlwork.com)
"JimLad" <ja*********@yahoo.co.ukwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Hi,

We have a major ASP app that we are in the process of upgrading to
ASP.NET 1.1 and probably on to ASP.NET 2.0 in the middle of next year.
(We will also be upgrading to SQL2K5 at the same time).

The current architecture is heavily based on the client side, both for
validation and data access. The asp page is returned and then data is
modified or selected using XMLHTTP objects embedded on the page, which
post or get to a data enabled virtual directory. Within this we use a
multitude of different SQL XML techniques including updategrams, XML
Views, XML Templates and straight http queries. There is a little bit
of ADO access.

At the moment, upgrading a page to ASP.NET simply means separating off
the server side code to code behind (which is easy due to decent asp
page formatting) and strongly typing all the variables (and a few other
bits and pieces). The major benefit of this is the ease of debugging in
ASP.NET as opposed to the hideousness of debugging ASP. However it
still leaves all the data access on the client side and essentially
leaves us with legacy code that is still heavily client based. Because
we have not done much with the ASP.NET, developers are still creating
new pages by copying and altering existing ASP pages. I have been asked
to come up with some recommendations on what to do. I'm not talking
unlimited budget, but this app will be our major solution for the next
5 years so we need to get it into a decent state that can be supported
and can utilise the benefits of asp.net. It may be that we need a
different upgrade route for existing pages and for creating new pages.
Atthe moment we're sort of stuck halfway between the 2 technologies.

I'm afraid that while I can code an ASP.NET website, I am no expert.
I'm very much a SQL Server guy. So I would appreciate any advice that
anyone can give or pointers to good articles. What is the general
consensus on using data enabled virtual directories from an app? How
hard would it be, and would it be worth the effort, to recode to use
ADO.NET or SQLXML managed classes and scrap the data enabled virtual
directory?

Sorry if I'm asking the wrong questions. The current architecture is so
antithetical to ASP.NET that it's difficult to see what can be done.
Beyond recommending that we immediately do the basic conversion of all
ASP pages to ASP.NET, I'm a bit stumped. It seems like it would be a
major project to make any kind of changes at all. Advice please!

Cheers,

James

Oct 16 '06 #4

P: n/a

I concur.

Based on the type of questions you are asking, you'd be better off making a
clean break and going to C#.... in order to NOT bring the bad habits of VB6
with you.

And there's no reason to wait to go to 2.0.

.........

Asp.NET is NOT Asp. Copying and Pasting is the worst thing you can do.

The other thing I've seen people try and do, (I think I tried this myself in
the beginning) is that you don't use ADO recordsets anymore.

You need to figure out how to use DataSets, Typed DataSets, and
IDataReaders. Esp in a web environment.


"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:uY**************@TK2MSFTNGP03.phx.gbl...
First bit of advice: go directly to 2.0. No reason to bite the bullet
twice.
>
I would also aim at figuring out the use cases (how the site is actually
used) before coding anything. You have the potential of working one use
case
at a time and having temporary co-existence of ASP and ASP.NET, but it si
best to isolate usage first so you have a clean path. Page by page does
not
normally work in this way, because ASP architecture has functionality
spread
across multiple pages.

Aim for writing a new application rather than a rewrite. Fix the
annoyances
as you "upgrade". While this may seem obvious, I have seen many managers
who
assume it is "just an upgrade" when, in reality, it is a new application.
Only by keeping this in the forefront will you keep your sanity. :-)

I would also consider writing in C#. While you do not leverage your
VBScript
to VB.NET skills, you will be less likely to bring VB baggage along for
the
ride. It is easier to make a paradigm change with a language change than
without.

MSDN has some articles on upgrading from classic ASP to ASP.NET.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************************************************
Think outside of the box!
*************************************************
"JimLad" <ja*********@yahoo.co.ukwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
Hi,

We have a major ASP app that we are in the process of upgrading to
ASP.NET 1.1 and probably on to ASP.NET 2.0 in the middle of next year.
(We will also be upgrading to SQL2K5 at the same time).

The current architecture is heavily based on the client side, both for
validation and data access. The asp page is returned and then data is
modified or selected using XMLHTTP objects embedded on the page, which
post or get to a data enabled virtual directory. Within this we use a
multitude of different SQL XML techniques including updategrams, XML
Views, XML Templates and straight http queries. There is a little bit
of ADO access.

At the moment, upgrading a page to ASP.NET simply means separating off
the server side code to code behind (which is easy due to decent asp
page formatting) and strongly typing all the variables (and a few other
bits and pieces). The major benefit of this is the ease of debugging in
ASP.NET as opposed to the hideousness of debugging ASP. However it
still leaves all the data access on the client side and essentially
leaves us with legacy code that is still heavily client based. Because
we have not done much with the ASP.NET, developers are still creating
new pages by copying and altering existing ASP pages. I have been asked
to come up with some recommendations on what to do. I'm not talking
unlimited budget, but this app will be our major solution for the next
5 years so we need to get it into a decent state that can be supported
and can utilise the benefits of asp.net. It may be that we need a
different upgrade route for existing pages and for creating new pages.
Atthe moment we're sort of stuck halfway between the 2 technologies.

I'm afraid that while I can code an ASP.NET website, I am no expert.
I'm very much a SQL Server guy. So I would appreciate any advice that
anyone can give or pointers to good articles. What is the general
consensus on using data enabled virtual directories from an app? How
hard would it be, and would it be worth the effort, to recode to use
ADO.NET or SQLXML managed classes and scrap the data enabled virtual
directory?

Sorry if I'm asking the wrong questions. The current architecture is so
antithetical to ASP.NET that it's difficult to see what can be done.
Beyond recommending that we immediately do the basic conversion of all
ASP pages to ASP.NET, I'm a bit stumped. It seems like it would be a
major project to make any kind of changes at all. Advice please!

Cheers,

James


Oct 16 '06 #5

P: n/a
Thanks for the advice everyone. Looks like we're gonna continue with
our half and half 'solution'(?). Not my choice, but there you go...

;o)
sloan wrote:
I concur.

Based on the type of questions you are asking, you'd be better off making a
clean break and going to C#.... in order to NOT bring the bad habits of VB6
with you.

And there's no reason to wait to go to 2.0.

........

Asp.NET is NOT Asp. Copying and Pasting is the worst thing you can do.

The other thing I've seen people try and do, (I think I tried this myself in
the beginning) is that you don't use ADO recordsets anymore.

You need to figure out how to use DataSets, Typed DataSets, and
IDataReaders. Esp in a web environment.


"Cowboy (Gregory A. Beamer)" <No************@comcast.netNoSpamMwrote in
message news:uY**************@TK2MSFTNGP03.phx.gbl...
First bit of advice: go directly to 2.0. No reason to bite the bullet
twice.

I would also aim at figuring out the use cases (how the site is actually
used) before coding anything. You have the potential of working one use
case
at a time and having temporary co-existence of ASP and ASP.NET, but it si
best to isolate usage first so you have a clean path. Page by page does
not
normally work in this way, because ASP architecture has functionality
spread
across multiple pages.

Aim for writing a new application rather than a rewrite. Fix the
annoyances
as you "upgrade". While this may seem obvious, I have seen many managers
who
assume it is "just an upgrade" when, in reality, it is a new application.
Only by keeping this in the forefront will you keep your sanity. :-)

I would also consider writing in C#. While you do not leverage your
VBScript
to VB.NET skills, you will be less likely to bring VB baggage along for
the
ride. It is easier to make a paradigm change with a language change than
without.

MSDN has some articles on upgrading from classic ASP to ASP.NET.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Oct 17 '06 #6

P: n/a
"JimLad" <ja*********@yahoo.co.ukwrote in message
news:11*********************@k70g2000cwa.googlegro ups.com...
Thanks for the advice everyone. Looks like we're gonna continue with
our half and half 'solution'(?). Not my choice, but there you go...
Your company is making a huge and potentially *very* costly mistake - you
should tell your boss this...

If the replies in this newsgroup aren't persuasion enough, I'd strongly
suggest you start looking for another job immediately.
Oct 17 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.