johnf wrote: > 2. Changing where we get the fields info. > This I think might screws up stuff????
Field info can come from the following places: 1) getFields(). Only applies to actual table fields on the backend. You'll get more information back than you need (not all the fields are in your actual query). You'll get less information back than you need (no information on derived fields). It is useful as a fallback when otherwise you have no information. 2) getStructureDescription(). I've recently rewritten this to be generic (see dBackend.py in my branch). This gets the field structure from the current query. It executes a no-records query behind the scenes if necessary. It calls getDaboFieldType() to convert whatever identifier came from the backend into the dabo types like "I" or "C". It also calls getFields() and will use that information if it is better info than what we got from cursor.description. getStructureDescription() is how cursor.DataStructure gets its information, if it wasn't set explicitly by the app developer. 3) App developer explicitly sets the information, via the DataStructure property. I heartily recommend this approach for your applications, however we still need to have sane defaults for when this doesn't get set explicitly. So, for mssql.py (sorry, I haven't even looked at it yet) you need to override getDaboFieldType() to return the right dabo types given the mssql types. You should also override getFields() to use whatever method (information_schema, describe, whatever) to provide a fallback for when cursor.description fails (it may or may not fail for mssql, I have no idea). But, you should not focus on getFields(), unless it proves necessary. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
