DataMgr 2.2 Beta 2

Coming nearly four months after the previous beta, DataMgr 2.2 Beta 2 is finally ready. I regret having taken so long to get this build completed, but I am happy with the results.

(What is DataMgr?)


  • New method: getFieldLengths()
  • New method: removeTable()
  • New relation type: "hasnot"
  • Enhanced method: removeColumn()
  • Enhanced method: updateRecords()
  • Enhanced relation type: "math"
  • Improved Seeding
  • Bug Fixes

New Method: getFieldLength()

This feature was another great idea by John Whish. The method takes a table name as an argument and returns a structure of every string field with a length limit. Each key is the name of a field and each value is the maximum number of characters allowed in that field.

New Method: removeTable()

This feature was suggested by John Farrar. I have initially resisted allowing destructive changes to happen from DataMgr, but John has shown me the light. I now have destructive features, but they must be called explicitely (I may allow an option for the "loadXml" method to be destructive, but I haven't decided yet).

This method takes a table name as an argument and removes it from DataMgr's memory as well as the database itself.

New Relation Type: "hasnot"

I added the "has" relation type in DataMgr 2.2 Alpha 2. It indicates "true" for string fields with a length of more than zero or numeric fields with a value greater than zero or non-null date fields, false in other case. The "hasnot" relation field simply returns the opposite boolean value.

Enhanced Method: removeColumn()

Andrea Campolonghi rightly pointed out that this method should work on relation fields as well as database fields. So, now it does.

Enhanced Method: updateRecords()

The "data_where" argument is now optional - allowing this method to be used to update every record in a table.

Enhanced Relation Type: "math

I added the "math" relation type in DataMgr 2.2 Alpha 2. I have changed it so that either "field" argument will accept either a field name or a number to be used in the math. I initially decided against this as I wanted to discourage hard-coding values. Then I needed to do some math with "60" (for the number of minutes in an hour) and changed my mind.

<field ColumnName="TotalMinutes">


Improved Seeding

This was another great suggestion from John Farrar. One of the problems with seeding data with the "loadXml" method has always been that it is difficult to change the data for new versions of a product.

John suggested added a "checkFields" attribute to the "data" element. This specifies which combination of fields should be checked for existence to decide if a record should be added to the database. The attribute is a comma-delimited list of fields.

So, without this attribute, a record will be added to the table unless a record is found matching every field in the row. With the "checkFields" attribute, it will only be added if no record is found matching the values of the fields in the "checkFields" list (this only matters if permanentRows is set to "true").

<data table="genPrograms" permanentRows="true" checkFields="ProgramName,ZipFinal">
      Description="I manage site administrators and administrative logins."

      ProgramName="Bug Tracker"
      Description="I track errors and bugs."

      ProgramName="Events Calendar"
      Description="I manage events and optionally display on calendar - includes repeating events."


With the above example, I could change any field other than "ProgramName" or "ZipFinal" (the fields in the "checkFields" attribute) and it would result in the record being changed instead of added.

Bug Fixes

This build also included a number of bug fixes. I thought it would be helpful if I listed those fixes briefly this time.

  • issue with date fields
  • Object returned from init()
  • Potential for duplicate field in "ORDER BY"
  • Filters
  • "IN" filter
  • Filtering for empty strings as NULL
  • Potential syntax error in update
  • Limitation with concat in MSSQL
  • Database introspection in Oracle


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

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
OK, that was close. :) But if the check fields are there... say you have an admin field in the database as default. Well if that record was updated you wouldn't want to have the activeSchema change things back. So, great on the not adding a new record BUT... my thought was if the checkFields were in existance it would be 'non-destructive' vs updating. Of course that is just my preference.

So, as it sits now. If we had a user of "admin" and a password of "changeme"... and it checked the field user and found "admin" already existed it would change the password back to "changeme". My thought was if the key values are in place then have it ignore the update. We could perhaps have something else but that was my target. Sorry for not expressing that better before now.
# Posted By John Farrar | 10/22/08 1:12 PM

Sorry about that. Not knowing how you wanted it to work, I made it work to address a need I had at the time.

What if I added an "onexists" attribute to the database element? It could have a value of "ignore" (what you want) or "update" (to meet my current need).
# Posted By Steve Bryant | 10/22/08 1:24 PM
That is awsome. I was going to ask but my brain is so deep in creating something today couldn't shift gears enough to come up with that. Sweet, simple and nice. I would suggest that default would be ignore... but can deal with it and be happy on many levels no matter what the default is.
# Posted By John Farrar | 10/22/08 1:26 PM
Good work Steve. Really like the improved data seeding feature, very cool idea to add an onexists attribute.
# Posted By John Whish | 10/23/08 2:41 AM



That change is ready now on the BER and the default is "ignore". Barring the unexpected, that will be part of the next beta.
# Posted By Steve Bryant | 10/23/08 9:29 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.