By: Nick Hodges
Abstract: This article discusses the genesis and use of the DBXDataSource component in ASP.NET and Delphi
An interesting thing happened on the way to ASP.NET 2.0.
First, let’s talk about typing and databases. You’d think by now that we, as an industry, would have a pretty good grip on the types of fields a database can handle. There are standards for date, time, timestamp and floating point data types. However, not all vendors follow the standard. Competitive pressures, the need for differentiation, and human nature all being what they are, prominent databases seem to handle some fields just a little bit differently. Maybe they have different integer types. Maybe they have one integer type that holds them all. Maybe they have different kinds of floating point numbers, maybe they just have one. In any event, everyone seems to do many common things just a little different.
Now, here at CodeGear, we’ve always prided ourselves on supporting a wide variety of popular databases. We’d like to make it easier for us to support even more than we do. That’s part of the strategy with our dbExpress 4 technology. One of its key design goals was to make it easier to write and maintain database drivers. Now, of course, one of the keys to that is to be able to abstract out the concept of data types, and to provide a set of types that will work for the VCL components that Delphi and C++Builder developers will use. You use the basic types we provide, and we “coerce” them into the right form to fit the database backend you are using. It shouldn’t matter at the code level whether the database is Interbase, Oracle, MySQL, SQL Server, whatever. We just want you to worry about your code, not your database types, and we particularly don’t want you to worry about how your database deals with blobs or Memos or DateTimes.
However, not all companies are so “flexible”. Some of them tend to prefer the database and data types of the database product that they want you to use. This sort of thing sometimes shows up in frameworks that get written. Take, for instance, the SQLDataSource component that is part of the ASP.NET 2.0 framework. This component, in theory, should be able to handle any ADO.NET 2.0 compatible datasource. And to be fair, it does. Sort of. But it uses the System.Type typing system of the .Net Framework. It only handles those types and no others. It also is smart enough to map these types to -- you guessed it -- SQL Server. But those are the only types it handles. So if you want to plug a datasource into it that doesn't exclusively deal with the System.Type namespace of types, well, then you've got some work to do. This is understandable, really – I guess you can’t marshal types for every database out there.
Microsoft themselves realized this, because they have another database engine that people use – Access. Access’s types aren’t the same as SQL Server’s, and they aren’t the same as the System.Type namespace’s types. Therefore, they had to create a new class – AccessDataSource – to connect up to an Access database for ASP.NET. AccessDataSource descends from SQLDataSource, and the basic difference is that it overrides the typing of parameter that pass through it, coercing them into the right types to be handled by Access.
Well, now for the interesting part. dbExpress and the dbExpress drivers are in the same boat as Access was. SQLDataSource deals in types that aren’t perfectly coincident with the world of dbExpress data types. So we had to create our own control for ASP.NET – DBXDataSource. DBXDataSource is a relatively simple control – it merely overrides eight methods of SQLDataSource to provide the type coercion needed to match up the types that ASP.NET uses with the types that our dbExpress drivers use.
The result? If you are developing ASP.NET 2.0 applications with Delphi, and you want to access data via dbExpress, then use the DBXDataSource component, not the SQLDataSource. (SQLDataSource is still there, and you can use it for SQL Server data if you like). With the DBXDataSource driver, you can connect up and use data from any of the nine dbExpress drivers – including InterBase and Blackfish SQL. DBXDataSource works just like SQLDatasource – it’s a direct descendent – so there's no compatibility problem with ASP.NET
And that is pretty much it – there’s nothing else really special going on here. The thing to remember: When accessing data in an ASP.NET application via dbExpress, use DBXDataSource in exactly the same way that you’d use a SQLDataSource component.
So, in the end, the summary is clear: Use DBXDataSource to access dbExpress data in ASP.NET 2.0. But here’s the fun part. This all happened relatively quickly once we realized that it would be an issue. We were able to be “agile” with this. From the time we recognized the problem to the time we had a tested component on the Component Palette was about a week or so. And in the end, you get a flexible, powerful DataSource for serving up ASP.NET Data.
Try Delphi XE4 free for 30 days
New Instant Trial!
Webinars on demand!
More social media choices:
Delphi on Google+
@RADTools on Twitter
Server Response from: ETNASC02