DataMgr 2.2 Beta 1

This is the first release of DataMgr wherein I can't take credit for any of the new features. Although this is a beta release, it should be pretty stable as I am running all of my live sites on it.

(What is DataMgr?)

New Features:

• Automatically Determine Database
• removeColumn()
• updateRecords()
• deleteRecords()

Automatically Determine Database

While attending a presentation, Mark Mandel mentioned that Transfer could automatically determine the database being used from the datasource name. He mentioned that it was easy and didn't take much code.

I thought this was a great feature. I asked Mark if I could use his code to add the feature to DataMgr. He consented and even helped me find the relevant code.

Consequently, the second argument of the "init" method (database) is no longer required. I have to say (with all credit to Mark Mandel) that this is one of my favorite new features in a while.

removeColumn()

This was a suggestion from Mark Mazelin to allow a column to be removed from the database using DataMgr. He also suggested a removeTable() method, but I haven't gotten to that yet.

Arguments:

• tablename: The name of the table from which a field should be removed.
• field: The name of the field to remove

updateRecords()

John Whish recently had a blog entry about his DAO/Gateway hybrid. In it, he has an update() method that allows multiple records to be updated. DataMgr has an updateRecord() method that only updates one record. At first as was skeptical of his approach, but after hearing his perspective on it some more, I was sold - to the extent that I went ahead and added the feature to DataMgr.

Arguments:

• tablename
• data_set: structure of data to set
• data_where: structure indicating which records to update
• filters: array of filters on which records to update.

deleteRecords()

This method has actually exists internally (with access="private") for some time. My recent discussion with John Whish, however, has convinced me that it makes sense to make this method public.

Arguments:

• tablename
• data: structure of records to delete

A Word on SQL Injection

This isn't a new feature, but given the recent SQL injection attacks, I felt it wise to bring up. DataMgr is inherently safe from these attacks. All variables that are passes to SQL are protected. Although field and table names are dynamic, they are verified to exist before being included in the SQL code. All incoming data is scrubbed first by checking data type and then by using CreateODBCDateTime() or .

The only way queries run from DataMgr can be vulnerable is if you call runSQL() or runSQLArray() directly or if you use the "advsql" argument of getRecords(). In both cases, the vulnerability would still depend on using dynamic values within that data.

Download

DataMgr is open source and free for any use. Download 2.2 Beta 1 from the DataMgr page on my site.