![]() |
|
|
Published: Saturday, July 17, 1999 By Ryan S. I'm back again for another fun filled tutorial going into the depths of the unknown to bring back a little bit of new knowledge to help make everyone's life easier. You should realize now that I always like to have little speil at the beginning of the article, and this one's no exception. So, while I could talk about some extremely technical topic, I'll get everyone OFF-topic and tell them to go to www.torley.com .... It's got music for just about every taste. Anyway, onto the article.
As some of you may or may not know, often my articles deal with SQL. Now, just so you realize, I don't know jack about SQL ;-) Anything I have learned I have found out by searchin' the ASP pages and just checking out the docs. If I can't find what I need, I make it. Anyway, what I'm going to discuss today is utilizing custom recordsets. Yes, that's right, I said CUSTOM. You probably know what a recordset is and how to either explicity or implicity create it, and of course you are probably aware of the various cursor and lock types. However, have you ever wanted to create a recordset without creating a table on the server, or just keep from hitting up the ODBC drivers a whole bunch each time you want to update a table? Well, besides using disconnected recordsets, you can use custom recordsets. Custom recordsets are, as the name implies, custom. That means made by you. Defined by you. Created by you. Controlled by you. Enough of those "by yous"... Any more and we would have a few megalomaniacs on our hands ;-) Anyway, you probably already have an idea of how you would use them, but since I try to keep my tutorials on a "... For Dummies" level, I'll assume that you have no clue in the heck why you would want to use a custom recordset. The example that I will use is a very simple one: A user database. Now, while some of you may hate me, I personally happen to like using Application wide variables. However, they have to be treated with special care. You have to Lock/Unlock your Application variables each time you use them, so there's not a sharing violation. (We don't want two people trying to tinker around with the same Application variable at the same time!) Now, in a custom recordset, first you have to define your variable as a recordset. This is accomplished by:
Next, you must add fields to it. Now, in pristine conditions, you are using your custom recordset in a VB environment, meaning you can use all of the built-in field types. However, because the world is not pristine, you may have to declare some field types. Also note that you only want to call your "creating" code once, or you can blow off your code. Another reason to use a VB object is the Private Function vs Public Function =D Anyway, you add a field by using the following syntax:
And you are ready to access all the fields. Just do:
or
or
(where x is the index of the field) and you are ready to rumble. Now for the sample app. Let's say we want to keep track of how many users are online, such as Aspin.com does, but we also want to be able to have an admin page to see all the users. We will be tracking the users IP, the users ID, and the time they first logged on. Ok, here goes the code: First, we need to have our global.asa file updated, to create our custom recordset as well as keep track of users logging on/off.
Now you have an application-wide variable, a recordset, called
each time we want to use it in a page. Now, you should have working code. You can
try to access the Now, how in the hell do you use these custom recordsets in your ASP pages? Well, let's look at that in Part 2!
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||