Stan,

Boolean values are displayed based on the method set by the component that you are using to view the data, not the database engine or the ODBC driver.  For example, if you start Atrex and go to Reports - SQL Query then query a table, you will see the fields as check boxes.

From a data entry perspective, 1/0 or T/F are equivalent, so too is TRUE/FALSE.

I disagree. The database must store those data with a specific binary representation. TRUE/FALSE, T/F, 0/1 are not all equivalent when looking at the binary data. The database, driver, or interface may provide convenience wrapping around the stored value. 

For example, MySQL provides a BOOLEAN datatype that's simply an alias for TINYINT(1). I can work with those data using the Boolean literals TRUE/FALSE, but the underlying data are not stored as "TRUE" or "FALSE". They're stored as a 0 or 1. 

In my test, I have updated pypyodbc to output the raw binary data received from the ODBC driver before any processing occurs. This provides me a way to visualize the raw binary data provided directly from the ODBC driver itself. I'm observing that these data contain ASCII encoded characters 'T' and 'F'. 

Again, based on the documentation provided by Elevate DB 2, I expect that the BOOLEAN datatype is really stored as an integer value 0 or 1. Which suggests that the ODBC driver is converting that into a character somewhere along the way. 

Internally EDB stores booleans as a binary bit with a value of 0, 1 or null.   The documentation reference that you are pointing to indicates that you can use T/F, 0/1, True/False to specify the value of a boolean as part of a query, NOT how it's returned via ODBC.  The ODBC driver is by definition a translation layer so that the data can be used from any data consumer, so how it presents to the data consumer side is dependent upon how your development language handles boolean values from the ODBC layer.   

Yes, I agree that the ODBC driver is a transition layer that provides me with access to the underlying data. I've removed the development language from the equation, and cut directly to the memory block returned by the driver. This makes the results language agnostic, with the only consistency coming from the ODBC driver. 

My problem is that the ODBC driver does not maintain consistency of those data. It's applying a transformation that neither represents the Boolean literal nor the actual numeric value. Nowhere in the Elevate DB 2 documentation do they mention that T/F is an acceptable presentation of those data.

I do concede that pypyodbc's handling of the returned value needs to be more robust. Microstrategy's ODBC connector correctly interprets the text values of 'T' and 'F' and presents them as TRUE/FALSE Boolean literals. 

I still think that this is a problem inherent in the ODBC connector. But as I now have a workaround, I will not push this further.