CCADO Classes in Dynamics AX 4.0
I wanted to take a quick break from my series on the future of Dynamics AX and Web 2.0, and talk a little bit about the CCADO classes. These classes represent a new way to access external data through code within DAX, which allows for the use of ADO vs. ODBC classes.
For me this is a wonderful step in the right direction, in which to be honest I missed. I missed the ability of creating object that represent table's through the use of ADO Recordsets. Now this is wonderful! The classes that are avaliable for this are:
CCADOConnection
CCADORecordSet
CCADOFields
CCADOField
The above classes can be made use to create an ADO connection to a given database, and then create multiple ADO RecordSets to work with.
Now let look at using these classes. When creating new code to make use of ADO Connection and recordset's, you always have to start with a connection. So the first class that you want to make use of would be the CCADOConnection object. With this object you can create your recordset through the use of a connection string. Once you have your connection, then you can build a recordset by creating a new CCADORecordSet object and call the .open() method with passing it the CCADOConnection open along with the T-SQL statement to retrieve the dataset with. The other two classes metioned above can be made use of for working with the Fields and a single Field within the RecordSet. Now there are other objects like the Command object which can be made use to execute updates and deletes, etc.
I want to mention here that all code should be design and developed in an OO way. Meaning that instead of working with raw Connections and RecordSets, you want to create objects that represent the data you are wanting to work with that handles the underlying updating, viewing, etc. With this you can then move forward in the right direction. To speak by example, if you have a table that contained: SID, UserName, Password, FirstName, LastName and you wanted to work with that table through ADO, then you would start out with creating an X++ class that represent the data as an object. So you would create a class that extended from the CCADORecordSet class that would have SID, UserName, Password, FirstName, and LastName as Parms of that class. The new would create the needed connection, and then you could choose to fill the who table and work with it as such, or supply a certian where clause to the end of the given T-SQL statement used to created and fill the object.
Well Check back soon as I continue on my path talking about the future for Dynamics AX and Web 2.0. The above though I wanted to get out here as it is Very useful, and very handy, and I am glad to see it replacing the use of the Older ODBCConnection classes.
Find a job at: www.DynamicsAXJobs.com
For me this is a wonderful step in the right direction, in which to be honest I missed. I missed the ability of creating object that represent table's through the use of ADO Recordsets. Now this is wonderful! The classes that are avaliable for this are:
CCADOConnection
CCADORecordSet
CCADOFields
CCADOField
The above classes can be made use to create an ADO connection to a given database, and then create multiple ADO RecordSets to work with.
Now let look at using these classes. When creating new code to make use of ADO Connection and recordset's, you always have to start with a connection. So the first class that you want to make use of would be the CCADOConnection object. With this object you can create your recordset through the use of a connection string. Once you have your connection, then you can build a recordset by creating a new CCADORecordSet object and call the .open() method with passing it the CCADOConnection open along with the T-SQL statement to retrieve the dataset with. The other two classes metioned above can be made use of for working with the Fields and a single Field within the RecordSet. Now there are other objects like the Command object which can be made use to execute updates and deletes, etc.
I want to mention here that all code should be design and developed in an OO way. Meaning that instead of working with raw Connections and RecordSets, you want to create objects that represent the data you are wanting to work with that handles the underlying updating, viewing, etc. With this you can then move forward in the right direction. To speak by example, if you have a table that contained: SID, UserName, Password, FirstName, LastName and you wanted to work with that table through ADO, then you would start out with creating an X++ class that represent the data as an object. So you would create a class that extended from the CCADORecordSet class that would have SID, UserName, Password, FirstName, and LastName as Parms of that class. The new would create the needed connection, and then you could choose to fill the who table and work with it as such, or supply a certian where clause to the end of the given T-SQL statement used to created and fill the object.
Well Check back soon as I continue on my path talking about the future for Dynamics AX and Web 2.0. The above though I wanted to get out here as it is Very useful, and very handy, and I am glad to see it replacing the use of the Older ODBCConnection classes.
Find a job at: www.DynamicsAXJobs.com
posted by brandon | 12:19 PM
1 Comments:
Mkz,
First thanks for stopping by! Secondly I can't believe how long I have been using AX and never knew about the CCADO classes.
I just checked an instance of AX 3.0 and sure enough they are there. See I used ADO.Net when developing for C#, but made use of ODBCConnection, Statement, and ResultSet classes for working with Outside datasources, mainly because of when I looked at code for doing so, this is how I saw it.
All this time I could have made use of ADO??? Oh Well. Thanks for the update. I will make sure to post about, and your link soon!
-Brandon
Post a Comment
<< Home