Naming the returned fields #33

Closed
artiee opened this Issue Feb 25, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@artiee

artiee commented Feb 25, 2013

I noticed that when I test my application on my local machine, the returned fields look like this:

CREATED_DATE: ...

but when I move this app into server, the fields fetched look like this:

CreatedDate: ...

Database used is DB2. The ODBC-driver's version is different on the server than on my local machine, so I guess that is the reason for the above behavior.

However, the problem is that I am fetching field that has totally different name than CREATED_DATE. The field is named as SBCHA.

Why is the returned field translated (SBCHA -> CREATED_DATE)? How can I toggle this feature off?

@wankdanker

This comment has been minimized.

Show comment Hide comment
@wankdanker

wankdanker Feb 25, 2013

Collaborator

I am not familiar with DB2, but is there any way to tell if the column has a label? We use this code to grab the column name from here:

ret = SQLColAttribute(
    self->m_hStmt, //StatementHandle
    (SQLUSMALLINT)i+1,  //ColumnNumber
    SQL_DESC_LABEL, //FieldIdentifier
    columns[i].name, //CharacterAttributePtr
    (SQLSMALLINT)MAX_FIELD_SIZE, //BufferLength
    (SQLSMALLINT *)&buflen, //StringLengthPtr
    NULL); //NumericAttributePtr

Where SQL_DESC_LABEL is the attribute type we are requesting. IBM's DB2 9.7 docs describe SQL_DESC_LABEL (DB2 CLI/v2) as:

The column label is returned in CharacterAttributePtr. If the column does not have a label,
the column name or the column expression is returned. If the column is unlabeled and unnamed,
an empty string is returned.

It looks like SQL_DESC_NAME could be used instead, but Microsoft's documents indicate that is an ODBC 3.0 attribute. I'm not sure if it would cause other issues if we start using more features from ODBC 3.0.

Collaborator

wankdanker commented Feb 25, 2013

I am not familiar with DB2, but is there any way to tell if the column has a label? We use this code to grab the column name from here:

ret = SQLColAttribute(
    self->m_hStmt, //StatementHandle
    (SQLUSMALLINT)i+1,  //ColumnNumber
    SQL_DESC_LABEL, //FieldIdentifier
    columns[i].name, //CharacterAttributePtr
    (SQLSMALLINT)MAX_FIELD_SIZE, //BufferLength
    (SQLSMALLINT *)&buflen, //StringLengthPtr
    NULL); //NumericAttributePtr

Where SQL_DESC_LABEL is the attribute type we are requesting. IBM's DB2 9.7 docs describe SQL_DESC_LABEL (DB2 CLI/v2) as:

The column label is returned in CharacterAttributePtr. If the column does not have a label,
the column name or the column expression is returned. If the column is unlabeled and unnamed,
an empty string is returned.

It looks like SQL_DESC_NAME could be used instead, but Microsoft's documents indicate that is an ODBC 3.0 attribute. I'm not sure if it would cause other issues if we start using more features from ODBC 3.0.

@artiee

This comment has been minimized.

Show comment Hide comment
@artiee

artiee Feb 28, 2013

Thanks for your quick answer. I have no expertise on this issue. So, nothing holds the value "SBCHA" so it isn't possible to add functionality to toggle off using CharacterAttributePtr?

artiee commented Feb 28, 2013

Thanks for your quick answer. I have no expertise on this issue. So, nothing holds the value "SBCHA" so it isn't possible to add functionality to toggle off using CharacterAttributePtr?

@wankdanker

This comment has been minimized.

Show comment Hide comment
@wankdanker

wankdanker Jul 5, 2013

Collaborator

Hey @artiee,

I have added the STRICT_COLUMN_NAMES compile option that may help with your issue. It is only currently available from version v0.5.20 in my fork.

Thanks,

Dan

Collaborator

wankdanker commented Jul 5, 2013

Hey @artiee,

I have added the STRICT_COLUMN_NAMES compile option that may help with your issue. It is only currently available from version v0.5.20 in my fork.

Thanks,

Dan

@wankdanker

This comment has been minimized.

Show comment Hide comment
@wankdanker

wankdanker Oct 8, 2013

Collaborator

This was fixed and no response was given in 3 months. Closing.

Collaborator

wankdanker commented Oct 8, 2013

This was fixed and no response was given in 3 months. Closing.

@wankdanker wankdanker closed this Oct 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment