Interesting. When you move to .NET, you'll read a lot about garbage collection (GC) and how when you set an object to nothing under COM, it's immediately destroyed and the memory reclaimed, but in .NET that doesn't happen for an indeterminate period of time, until your application starts to come under memory pressure. That's what the IDisposable interface is all about, since setting a null reference doesn't work anymore now that our framework stopped using "reference counting" we need a Dispose() method to immediately free any resources, in case we're using something that could linger, like a database connection, GDI+ Graphics object, or a file handle.

And yes, I use GDI+ a lot in ASP.NET, it lets me create a jpeg in memory and save it down to the client. I've been trying to write a charting library, but it's harder than it looks. Still it's a good learning experience.

Anyway, I just thought that was really interesting, and that you would enjoy hearing (from the .NET fanatic no less) an example of how Old School ASP is maybe better. That, and it makes sense what you're saying, especially since it's the ASP server doing all the work in the Access file, right?

Oh, and while it sounds like we really need to be able to choose more than one thing, seems like almost everybody who answered works in multiple databases, but what I really wanted was to see which one pulls ahead. Right now it looks like MySQL is the most popular of the bunch. But it also looks like I left some of the niche ones out.

Originally Posted by ADAM Web Design

Hirst, I'm not sure what you mean by 1). Are you talking something like this:

<div><h1><% =Heading %></h1></div>
I've always found the opposite to be true, and I remember reading the same thing on a Microsoft document years and years ago.

Yep that's it. Going back to the days of IIS 4. It was quicker to do a response.write of the HTML because of the way the parser handled pages, as the entire source code was passed to the interpreter. This is why dumb Host Co's will always whinge about extra server load when changing application mappings to parse .htm(l) as ASP.
With IIS 5 came a different way of handling the executable code, now only the code inside the delimiters is sent to the interpreter and the returned data is mixed back into the HTML source.

Originally Posted by ADAM Web Design

I always Response.Write my code and I've never had a problem (except now I have a hard time creating an initial layout because I'm always quadruple-quoting attributes).

I still do this a lot on but avoid the quad quoting by response.write'ing a quote into the code

like so;

with response
.write "<a href="
.write chr(34)
.write "/directory/admin/login.asp?logout=yes"
.write chr(34)
.write " title="
.write chr(34)
.write "Logout "
.write chr(34)
.write ">"
.write "Logout"
.write "</a>"
.write vbCrLf
end with

I never could do the chr(34) routine. Then again, I don't code ASP in the "conventional" way. But to each their own, I guess. I know what you mean by it...I just never liked it. I tend to avoid using the chr function personally.

But to each their own, I guess.

I must admit, I am amazed at all of the connection creation and destruction per request. Are you guys doing that in an ASP instead of in a request handler?

In the J2EE world, we pool connections. Generally it goes like this, request comes in, gets handled by a servlet, this grabs data from a DAO (data access object) that deals with the database, then hands off to a JSP for rendering.
Basically, usage of the database connection is kept as short as possible, to leverage pooling. Rendering, as HTML, is separated completely from data access.
At my last company, we had highly customized (per user, per language, per region) pages, and traffic on the order of 3-6 million/day. 3 Oracle databases used by 20+ Linux frontend boxes.

ASP here. I'm unfamiliar with request handlers. Never did mess around with J2EE either (that whole Java thing never appealed to me).

Originally Posted by willcode4beer

In the J2EE world, we pool connections. Generally it goes like this, request comes in, gets handled by a servlet, this grabs data from a DAO (data access object) that deals with the database, then hands off to a JSP for rendering.

I don't know for sure about ASP, but ASP.NET uses connection pooling almost automatically. I think ASP does, too, this is encapsulated into the database access library.

Really? You still use DAO? I thought that was totally retired, but I guess I was mistaken. We use ADO.NET and ADO Old School. I'm not sure how much difference there is in DAO vs ADO besides what order the letters come?

The data access is part of the general processing, it just sort of happens wherever you program it. I don't use time stops the way Adam describes, I put all of my logic in a code-behind file and really only respond to events. So I might run, wait for, and render a query on the page load event. Or when a button is clicked.

Three Oracle servers to ten Linux web servers, huh?

Originally Posted by Learning Newbie

I don't know for sure about ASP, but ASP.NET uses connection pooling almost automatically. I think ASP does, too, this is encapsulated into the database access library.

Really? You still use DAO? I thought that was totally retired, but I guess I was mistaken. We use ADO.NET and ADO Old School. I'm not sure how much difference there is in DAO vs ADO besides what order the letters come?

The data access is part of the general processing, it just sort of happens wherever you program it. I don't use time stops the way Adam describes, I put all of my logic in a code-behind file and really only respond to events. So I might run, wait for, and render a query on the page load event. Or when a button is clicked.

Three Oracle servers to ten Linux web servers, huh?

DAO is just a design pattern (Data Access Object) not an actual library. There are a million way to implement, and it can be implemented with any language (ADO is an implementation of the pattern)
I use Hibernate, others prefer iBatis, some just roll their own. The point of that particular pattern is to keep your data access code isolated from the rest of your application code.
So in my application, I could replace Oracle with MySQL by changing the dialect entry in my Hibernate configuration. I could also drop Hibernate and replace it with something else by writing new implementations to my data access interfaces. None of the application code (search, pagination, data view/edit, etc) would need to be modified.


There were actually about 100 servers (ecomm, partners, media auth, yada yada yada) that talked to those Oracle boxes. The 20+ were the just the ones I cared about.

Access mostly, Oracle quite often, MySQL occasionally.

Will wait for Adam to expand on the experience of using Access seriously as he is really using it to its limit.

I am not spamming or promoting I just find this funny I saw a video called the world runs on mysql
it kind of has to do with these results