Collecting visitor information is a useful tool for any webmaster. Whether it's collecting suggestions to improve your site, or contact information for sales leads, visitor information is a valuable resource. The following download will allow your visitors to submit their name, email, and any comments.

It is written with a minimalist implementation and lots of comments to make it easier for you to customize to your site's needs. The code is good "out of the box", just unzip the files and put them on your webserver and you're all set (though you will want to add your own site's design around the code). If you wish to have the database file in another folder, make sure you update the strDatabasePath variable in BasicForm.asp

In this article we will learn how to display random records from the database. From the articles so far, you will be able to display records from the database in a variety of ways and do a lot with them. We will add to our ASP-Database knowledge by enabling our ASP scripts to show random records.

Here is an invaluable program that you can use to view and control the presentation of records in your database. We will use the Recordset object and the MaxRecords property via ADO, to set the number of records to return to the recordset and therefore to your screen. This is like a table in memory, holding records which are subdivided into individual fields.

In this article we will learn on how to use database transactions in ASP. This will allow us to execute all database queries or none at all. How many times have you wanted to insert, update a lot of records collectively wanting that either all of them get executed or if there is an error then none is executed at all ? Well, if you haven't this need yet, you will have it in near future.

This one's like a double whammie! Welcome to the world of hard core SQL Server stored procedures and to the NextRecordset method of ADO's recordset object... Before we go on, this requires SQL Server. WON'T WORK WITH ACCESS.

That said, the goal for this example was easy... Get a list of all current tables in the database created by your's truly, get a list of dependent stored procedures for each table and do it all in a stored procedure! Easy...

There are basically 2 parts to this example. The calling application (a VBScript class called SQLServerTools) and the SQL Server stored procedure: sp_Admin_ExampleTablesDependencies (included with the class). The VBScript class is easy and contains only 1 method. That method is a great example of how to use the NextRecordset method of ADO to capture a second (or 50th) recordset returned by a procedure. For example, did you know this was valid SQL:

"SELECT * FROM table1;SELECT * FROM table2;"

Well it is, SQL Server knows that this statement should produce two separate and distinct recordsets however if you execute that and don't use NextRecordset, you will only get that first RS back. The stored procedure I wrote to do all the work is the second part of the example. That procedure returns (2 * num of tables) recordsets which is variable and based on the number of tables found in sysobjects for your particular db. Bottom line, that procedure always returns more than 1 recordset.

Right now, as you read this, I estimate that the procedure returned as many as 30 recordsets that were looped through with NextRecordset... But that's not the real magic. The class only exists to call the procedure and work with it's results. The stored procedure itself does all the work.

I've commented both the app and the stored procedure to the max but I'll give you an overview of the stored procedure... The stored procedure uses a cursor to loop through the records of a recordset returned by the system table: sysobjects. The process used is almost the same as using ADO to manipulate a recordset but right in the db itself... this means huge speed bonus and, by writing a stored procedure, all that logic is forever contained within and isn't spilled out into the class where it doesn't belong.

So anyways, while the procedure is looping through each table returned by sysobjects, it's simultaneously calling the system stored procedure: sp_depends. sp_depends is a handy function that returns a recordset of names representing every stored procedure that references the entered table! sp_depends can be used on any object, not just tables, but that is another discussion for another day...