best approach question: C# library in ASP Classic, what about data sets?

[jason]

the enterprise is going to eventually convert the existing ASP Classic
website to ASP.NET

until that time, development has already begun for a C# library of
business objects. for the most part, the ASP Classic can make use of
the C# business objects without problem, because they were compiled and
registered through COM Interop.

however i have just reached a point of uncertainty: sets of data.
obviously C# has no problem using the ADO.NET objects to retrieve sets
of data, but so far the libraries can't seem to pass an SqlDataReader
object to ASP Classic, because those objects aren't COM friendly.

likewise, i haven't had much luck figuring out if/how C# can use ADO
Classic objects.

so that leaves me wondering how a C# class using COM Interop to be
instantiated in ASP Classic can pass an object with a set of data to
the ASP code.

thanks in advance for any help,

jason

[Nicholas Paldino [.NET/C# MVP]]

Jason,

I find this to be a pain point when trying to convert non-managed
data-manipulating apps to .NET. There isn't really a good story for
migration. Because you don't want to be stuck with the data model of ADO,
you don't want to use COM interop with the ADO COM libraries, but at the
same time, you want to protect the initial investment.

A proper design can help mitigate this somewhat, but it's still going to
be painful, because the core data container is changing. The best way I can
think of to get around this would be to develop your .NET code the way you
want it to be, without thought to the existing code. Then, I would write a
layer that would convert the data exposed by the .NET code in a manner that
can be consumed by your existing ASP application. The difficult part here
is that DataSets do not convert easily to Recordsets in ADO. It depends on
how complex your data is.

Using ADO in C# is easy. I believe the primary interop assemblies for
ADO are already included with the .NET framework. When you go to add a
reference, you should see it in the .NET section. If not, the list on the
COM tab will definitely contain the Microsoft ActiveX Data Objects.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"jason" <ia****@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

the enterprise is going to eventually convert the existing ASP Classic
website to ASP.NET

until that time, development has already begun for a C# library of
business objects. for the most part, the ASP Classic can make use of
the C# business objects without problem, because they were compiled and
registered through COM Interop.

however i have just reached a point of uncertainty: sets of data.
obviously C# has no problem using the ADO.NET objects to retrieve sets
of data, but so far the libraries can't seem to pass an SqlDataReader
object to ASP Classic, because those objects aren't COM friendly.

likewise, i haven't had much luck figuring out if/how C# can use ADO
Classic objects.

so that leaves me wondering how a C# class using COM Interop to be
instantiated in ASP Classic can pass an object with a set of data to
the ASP code.

thanks in advance for any help,

jason

[jason]

ok, i've gotten the ADO objects instantiating in my C# code, though now
i'm really boggled. i'm trying to build an ADO Recordset from a
standard ADO Command.Execute call, but the .NET implementation of the
Command.Execute requires three parameters that were optional in the old
ADO world. and they aren't the same types as the original either. they
want an out object for records affected, ref object for parameters, and
int for options.

i've been looking for clues on what to provide here, but so far i'm
getting a big WTF?

normally records affected wants an int. but an int for that parameter
generates a "cannot convert from int to out object". but if i give it
anything other than an int, i predict it will explode when it tries to
treat it like an int?

anyway, same story for the ref object for "Parameters". all my
parameters are being created/added before the Execute method is called.

any chance you can point me in the right direction for managing this
..NET version of the once-simple ADO Execute method?

thanks,

jason