Thank you for responding so quickly. The column in the database is defined as a time stamp. It seems as though OpenDBX doesn't understand that type. I'll try setting up date, date time, time, and timestamp columns and see what happens. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Pharo-OpenDBXDriver-Unsupported-data-type-UNKNOWN-tp47... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Also, see this old thread: http://forum.world.st/SqueakDBX-Can-t-parse-date-td1307447.html On Wed, Oct 22, 2014 at 8:45 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

What is the exact type in the database? See: http://www.linuxnetworks.de/doc/index.php/OpenDBX/DBMS_Datatypes

Is it a TIME STAMP? That page says: "[1] Implementations use DATETIME instead of TIMESTAMP as defined by the SQL standard" You may want to try using DATETIME instead?

Cheers,

On Wed, Oct 22, 2014 at 2:23 PM, bsselfridge@gmail.com < bsselfridge@gmail.com> wrote:

...

Thank you for responding so quickly. The column in the database is defined as a time stamp. It seems as though OpenDBX doesn't understand that type. I'll try setting up date, date time, time, and timestamp columns and see what happens.

----- Brad Selfridge -- View this message in context: http://forum.world.st/Pharo-OpenDBXDriver-Unsupported-data-type-UNKNOWN-tp47... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

Hi! Check that a row in Pharo's OpenDBX driver answers to: - #values it reads the value from the database and tries to convert it to the corresponding object representation (e.g., a mysql date to a pharo date) - #rawValues it returns a string representing the direct representation in mysql. So maybe if you use #rawValues you can query the database and do whatever you want with the "unparsed" value. Tell us if this helps you! Guille On Thu, Oct 23, 2014 at 3:40 AM, bsselfridge@gmail.com < bsselfridge@gmail.com> wrote:

Yes, the column type definition is: timestamp.

I am trying to use Pharo to access some old legacy MySQL tables. These tables have "timestamps" defined everywhere and there is NO WAY I will be allowed to change them. So, I'm going to have to try to figure out how to get around this problem.

Since I'm new to the Pharo camp, (old VASmalltalk'er using DB2 as database), do you think the OpenDBX people would be open to supporting timestamp in their library?

Brad Selfridge

----- Brad Selfridge -- View this message in context: http://forum.world.st/Pharo-OpenDBXDriver-Unsupported-data-type-UNKNOWN-tp47... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

there is a misunderstanding here (I think). the problem of the UNKNOWN type is not in OpenDBX but in the OpenDBXDriver. I remember I added the type UNKNOWN to all the... well, unknown types :) Since OpenDBX will give you a string with a timestamp, you can modify driver (a Pharo chunk of code) to adapt to your needs, without needing to modify more. for example (and always take into account that is been like 3yr since last time I seen this): when you instantiate a resultset you need to know the types, which comes from OpenDBX as a number, so you need to: detectNewTypes: aDBXResultSet notSupportedDescriptions keysAndValuesDo:[ :index :desc | | dbxType | dbxType := OpenDBX current apiQueryColumnType: aDBXResultSet handle index: (index - 1) . desc type: (aDBXResultSet dataTypeAt: dbxType); dbxType: dbxType. desc type isBehavior ifTrue:[ notSupportedDescriptions removeKey: index ] ] as you can see, that calls DBXResultSet>>#dataTypeAt: which at his time calls also #dataTypeAt: from the platform, who ends finally to answer something like this: at: 16rFF put: (DBXTypeNotSupported type: #UNKNOWN); (in DBXBackend>>#createDataTypesMap) So… my opinion is that you could twist something someplace there (like creating your own platform backend, derivate from your real backend, who instead DBXTypeNotSupported type: #UNKNOWN will answer TimeStamp). Of course this is an ugly hack, but can solve your problem. If you want to be sure that you just change the type for the scheme you want and not for all possible UNKNOWN types, you can override dataTypeAt: in DBXResultSet and check if the column you want to change is the one you want, then you can force the type to the one you want. Well… I can think in many other hacks that can solve your problem without changing opendbx.so and without changing either Glorp :) I suggest you to go in that direction. cheers, Esteban

On 28 Oct 2014, at 22:01, bsselfridge@gmail.com wrote

I've contacted the OpenDBX development group and they seem to be unwilling to add the "UNKNOWN" types to their library. So, that leaves us with solving the problem in the GLORP framework.

The big problem is the GlorpOpenDbxDriver is asking the DBXRow for its value - not rawValue, thereby triggering the DBXTypeNotSupported object to throw an exception. My suggestion is that framework needs to be enhanced to deal with this problem and not force every developer to have to bypass/override chunks of the Glorp framework whenever an "UNKNOWN" type is returned.

I have some ideas how to overcome this dilemma. However, I think that I may need to move this conversation to the Glorp group.

----- Brad Selfridge -- View this message in context: http://forum.world.st/Pharo-OpenDBXDriver-Unsupported-data-type-UNKNOWN-tp47... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.