Re: What is the best way to work with SQL SERVER data / tables?

CDMAPoster@xxxxxxxxxxxxxxxx wrote in
news:d7425d23-6bc5-48d6-a292-6a10a130bfb0@xxxxxxxxxxxxxxxxxxxxxxxxxxx:

Lyle,

I like ADODB. The only problem I had with it was that the ASP code I
wrote that used it against SQL Server worked so well that I didn't
have to learn any of the SQL Server specific optimizations in order to
make it run quickly enough :-).

I must make a decision soon about ASP and ADO versus ASP.NET. I find the
combination of ASP and ADO and SQL-Server and HTML and Client-side
JavaScript and DOM to be the most successful, rewarding and personally
fulfilling application development foundation that I have ever used. ADO
and ASP are thin technologies and they do their work and go away
instantly and gracefully. SQL-Server is an enormously powerful data
provider. When I sit down to create dynamic HTML, for the first time in a
long life, I believe I have some inkling of the creative delight that
artists must feel.
The best thing about these technologies is that they do almost nothing
for their users, but they reward the careful, industrious and studious
developer enormously.
With them I can always, or almost always say, ?I can do that, and it will
be pretty and fast.?

I can do .Net. I don?t enjoy it and I don?t like the results. Of course,
the one may cause the other. Perhaps if I embraced .Net and loved it and
studied its nuances and pursued its potential, it would respond in a
great bloom of beauty and utility. (Sounds like couple counselling?)

I have read that ADO Recordsets are not as efficient as ADO.Net Datasets.
This may be. With ASP, I use JavaScript. I convert my ADO Recordsets to
JavaScript arrays. Doing so is trivial. JavaScript arrays are ten
thousand times faster, more powerful and enabling than Datasets or
Recordsets.

So what shall I use? Another developer whom I respect a very great deal,
advises,
?For NEW applications it seems a no-brainer: ASP has been dead for 6+
years, and Asp.Net is the new way forward. Why is this even a discussion?
?.
Your client deserves a modern, supportable implementation.?

I feel both instructed and guilty and spend Saturday re-doing my ?proof
of concept page? with ASP.Net and ADO.Net. I compare the old ASP and ADO
page with this ?new way forward?.
Which is faster in loading? ASP and ADO win that one.
Which is prettier? ASP and ADO take this ribbon as well.
Which sends less HTML to the client? This one isn?t even close. The HTML
created by ASP is about 30% the size of that created by ASP.Net.
Which is more responsive? Not surprisingly, with server callbacks hanging
about like moss on a New Orleans oak the ASP.Net created HTML is
refreshed many more times, and more slowly than that created by ASP.

I am completely aware that these findings of mine might be entirely
reversed if another developer performed the task in each of the
technologies.

What about concurrency? Yes, ADO.Net provides mechanisms for dealing with
concurrent users. I think it wins here. If I were writing an application
where you and I are likely to be editing the same data I would strongly
consider ADO.Net. But I am not. In my application, you will be editing
your data and I will be editing mine. Even if there might be concurrent
editing problems, over the past 250 years, ( so it seems), of using ASP
and ADO, I have developed my own techniques for dealing with that
problem.

I backed off on using ADO because of
what YOU said about it. Plus, the application I wrote didn't require
dealing with the problem areas you encountered, such as Application
Roles. When you found an equivalent problem in DAO, your about-face
back to ADO was almost reminiscent of one of Microsoft's about-faces.

* ?your about-face back to ADO was almost reminiscent of one of
Microsoft's about-faces?. Being called ?rat-*** crazy? doesn?t hurt at
all but I?m bleeding at this comparison.
* I think I have miss-typed ?ADO? and ?ADP? at times, or that you and
others have not kept my opinions about the one, separate from my opinions
about the other. I think I have never abandoned ADO, but I have abandoned
and then returned to ADPs.
* I hope I am smart and secure enough to refresh my mind and thoughts
each morning, and not to be chained to my yesterday?s mind or thoughts.

Given all the vacillation that has taken place on the issue, your
criticism that Access programmers are not willing to embrace ADO in
the situations where it has clear advantages almost looks like sour
grapes over the development time you invested in ADO. I agree that
using DAO with ODBC to interact with SQL Server is not very
intellectually appealing and I have never even attempted that
combination, but I have no problem with someone who thinks about the
choice and makes their choice with a reason in mind. They heard your
views on views :-), so let them decide for themselves how badly they
need them. BTW, I liked your report generating code a lot, but it
should not be used to determine whether you're crazy or not since your
sanity is a completely separate issue. Your code makes me want to go
back and clean up my search form generating wizard.

I have no problem with ?someone who thinks about the choice and makes
their choice with a reason in mind? as well. There are developers who
post here who have gone both the ADP route and the ODBC route and prefer
the ODBC route. I rarely clash with them and often I learn from them. I
do have problems with the proponents of DAO or ODBC who denigrate ADO or
ADPs but have not used ADO or ADPs extensively. I am more accomplished in
ADO than they are. In almost all cases I am also more accomplished in DAO
than they are. When they attempt to demonstrate DAO?s superiority vis-a-
vis ADO by citing DAO techniques which I have explored, championed and
perfected in the past, I am astounded.

Thanks for your comments for they have encouraged me to think carefully
about ASP and ASP.Net and ADO and ADO.Net. Please, leave out the
reminiscent of Microsoft observations next time. You really know how to
hurt a guy.


--
lyle fairfield
.