Recordsets
As the name implies, it represents an entire set of records which would be returned by some SQL command. The main advantage of this is the ease that it provides in manipulating records and the fields within those records within the SQL database.
Cursors
Recordsets have a member called a “Cursor” within it. A cursor is the mechanism that allows the ease of modifiability of a recordset. There are four types of cursors for a recordset:
The above example has a Connection object declared and defined in line 5. Apparently, using the string “ADOB.Connection” allows for the interpreter to know that the conn variable is an instance of the ADOB.Connection class. The Data Provider member of the Connection class is set to be an OLE-DB type of database in the next line. The connection then opens a Microsoft Access database by using the directory value returned from the invocation of the Server.Mapath method and uses that as the parameters for the Open method of the Connection instance.
Next the recordset instance is created in line 9. A while loop is declared in line 11 with the “do until” syntax and it is defined in lines 11-19. Inside of this loop, a for-each loop is declared in line 12. Inside of the innermost loop, a variable of some unspecified type is instantiated for every Field that is listed within the recordset. Similar to Java Servlets, in my experience, a Response is involved here. The Response, it seems, has a static method called Write which allows for the ADO webpage to write an SQL query using the values found within x.
Datasets
According to the author of the source, it’s “not an upgrade” but “a complete redesign” of ADO. Since, I am not really familiar with ADO really, it’s not a big deal to me.
At the core of this framework is the System.Data namespace which is a library of classes that are intended for “back-end” related activities in a web application. The objects are what the author calls “disconnected”. The framework provides “a hierarchal, disconnected data cache” that works both online and offline. At the center of these “disconnected” objects is the DataSet. The author states that ADO .Net is meant to “bridge the gap” between “traditional” access to databases and access that involves XML.
Differences Between ADO and ADO .Net
ADO was not designed with XML and Service Oriented Architecture (SOA), according to the original author, in mind. One limitation to developing SOA applications within ADO is the inability to use stored procedures to modify databases. Many database admins only allow changes to be made by stored procedures, and with Cursor objects this is impossible to do.
The example on the left is an “object model” for the Connection, Recordset, and Fields objects from the ADO framework, and the one on the right is for the Database, Connection, Command, DataAdapter, Dataset, and Datareader objects. Assuming that the association shown in these diagrams are aggregation only and not that of a hierarchal nature (because, I think that VB is not a “true” oop language just like how JavaScript isn’t either), then my understanding is thus:
ADO : Connection object owns the Recordset object, which has as a member the Fields object.
ADO .Net : There’s a Database object which has as its member the Connection object. The Connection object has the Command object as its member. The Command object owns the DataAdapter object and the Datareader object. Lastly, the DataAdapter object owns the DataSet object.
As the name implies, it represents an entire set of records which would be returned by some SQL command. The main advantage of this is the ease that it provides in manipulating records and the fields within those records within the SQL database.
Cursors
Recordsets have a member called a “Cursor” within it. A cursor is the mechanism that allows the ease of modifiability of a recordset. There are four types of cursors for a recordset:
- Forward-only: The default cursor, it allows the user to view changes to a database (includes insertions, deletions, and updates), but only allows forward-scrolling movement in the database. This allows for improved performance.
- Dynamic: The same as above (or rather a forward-only cursor is a subtype of this class) but allows for backward-scrolling as well.
- Keyset: Bidirectional type of cursor only allows the user to see updates made to the database, but prevents access to newly inserted records and deleted records.
- Static: A different category of cursor from the other three, this one allows for forward and backward movement but doesn’t allow the user to see any kind of changes (inserts, updates, and deletions) made to that database.
Code:
<html>
<body>
<%
set conn=Server.CreateObject("ADODB.Connection")
conn.Provider="Microsoft.Jet.OLEDB.4.0"
conn.Open(Server.Mappath("northwind.mdb"))
set rs = Server.CreateObject("ADODB.recordset")
rs.Open "Select * from Customers", conn
do until rs.EOF
for each x in rs.Fields
Response.Write(x.name)
Response.Write(" = ")
Response.Write(x.value & "<br />")
next
Response.Write("<br />")
rs.MoveNext
loop
rs.close
conn.close
%>
</body>
</html>The above example has a Connection object declared and defined in line 5. Apparently, using the string “ADOB.Connection” allows for the interpreter to know that the conn variable is an instance of the ADOB.Connection class. The Data Provider member of the Connection class is set to be an OLE-DB type of database in the next line. The connection then opens a Microsoft Access database by using the directory value returned from the invocation of the Server.Mapath method and uses that as the parameters for the Open method of the Connection instance.
Next the recordset instance is created in line 9. A while loop is declared in line 11 with the “do until” syntax and it is defined in lines 11-19. Inside of this loop, a for-each loop is declared in line 12. Inside of the innermost loop, a variable of some unspecified type is instantiated for every Field that is listed within the recordset. Similar to Java Servlets, in my experience, a Response is involved here. The Response, it seems, has a static method called Write which allows for the ADO webpage to write an SQL query using the values found within x.
Note: I found that there are no such things as “static” methods or variables in Visual Basic. Rather, “Static” functions and variables are declared at “procedure-level”. I’m not sure what that means exactly, but assuming that the word “procedure” is used synonymously with words like “method”, “function”, or “routine” then it’s likely only used inside of, what I might call a “method”, in Visual Basic (MSDN).
From what I see, it looks like the values for x are set to what they were already. In line 15, I’m guessing that the ‘&’ allows for string concatenation, similar to how C# and Java allow the ‘+’ operator to be used for the same purpose.
Datasets
According to the author of the source, it’s “not an upgrade” but “a complete redesign” of ADO. Since, I am not really familiar with ADO really, it’s not a big deal to me.
At the core of this framework is the System.Data namespace which is a library of classes that are intended for “back-end” related activities in a web application. The objects are what the author calls “disconnected”. The framework provides “a hierarchal, disconnected data cache” that works both online and offline. At the center of these “disconnected” objects is the DataSet. The author states that ADO .Net is meant to “bridge the gap” between “traditional” access to databases and access that involves XML.
Differences Between ADO and ADO .Net
ADO was not designed with XML and Service Oriented Architecture (SOA), according to the original author, in mind. One limitation to developing SOA applications within ADO is the inability to use stored procedures to modify databases. Many database admins only allow changes to be made by stored procedures, and with Cursor objects this is impossible to do.
The example on the left is an “object model” for the Connection, Recordset, and Fields objects from the ADO framework, and the one on the right is for the Database, Connection, Command, DataAdapter, Dataset, and Datareader objects. Assuming that the association shown in these diagrams are aggregation only and not that of a hierarchal nature (because, I think that VB is not a “true” oop language just like how JavaScript isn’t either), then my understanding is thus:
ADO : Connection object owns the Recordset object, which has as a member the Fields object.
ADO .Net : There’s a Database object which has as its member the Connection object. The Connection object has the Command object as its member. The Command object owns the DataAdapter object and the Datareader object. Lastly, the DataAdapter object owns the DataSet object.
Note: Not shown in the diagram above is the Transaction object, which is instantiated from the Connection object through the BeginTransaction method.
