March 30th, 2011, 08:46 AM
FORCING SQL Query Return Types (DBI)
Hi. I am an SQL-DBA, not a PERL-programmer, but I have been approached by a programmer who has difficulty with return types from SQL.
He queries a table on the SQL-server storing many values as floating point numbers (most or all can be represented as integers). The programmer uses CAST(column_name AS INT) on several columns in his query, iterates the results (loading them into an array of variables) and prints them with an automatic string conversion: print("$colvar1; $colvar2...").
He is quite upset with my SQL-server for returning floats when he has cast his columns to int. I believe my poor SQL-server is already doing what it can, and I know that the perl programmer can make explicit casts on the assigned variables, but I'm not off the hook until the query returns integer values all around. Unless that can for some reason not be done. I might eventually be able to convince him that some formatted print method is the ideal solution, and that this is not a failure of the SQL-server.
Data source: MS SQL Server 2008
ODBC Provider: Microsoft SQL Server DSN
PERL Version 5.8.7
My questions to you:
A) Where is this behaviour introduced?
Behaviour: Not getting the appropriate type from a CAST in SQL
Suggested layers: ODBC provider, Perl runtime / DBI
B) Is it possible to get appropriately typed data directly from the SQL-query?
C) What is the ideal method for fetching floating point numbers from sql and displaying them as integer values?
I haven't posted any code, as solutions need not be based on existing code. If you think that code would provide information not otherwise available in this post, I can get at it, but I'll only do so if it makes a big difference. (If I ask for access to his scripts, it becomes personal. Again.)
All advice is appreciated.
March 30th, 2011, 10:13 AM
March 30th, 2011, 10:34 AM
Thank you. I feel that "printf" looks like the best method. Although the developer expects me to solve this through SQL-server. What I've read about parameter binding so far, suggests that the ODBC-driver would be able to provide a data type. Perhaps the CAST-function's ability to return various types of data causes this particular ODBC-driver to be unspecific about what it returns.
I'll play around with both ends and anything inbetween for a while, and see what I can learn whilst solving the angry programmer's problem.
March 30th, 2011, 11:52 AM
Your angry programmer must not know very much Perl since what you're needing is entry level knowledge and 5 minutes of reading the documentation for the ODBC module.
March 31st, 2011, 08:31 AM
But in the end, he actually found the answer he was looking for: The MS SQL Server ODBC Driver regional settings are massively flawed and break lots of applications - turn it off.
While he could have made his script work independently of this, he is a much happier man now that he has made a useful change to his ODBC configuration (proving to him that his script was not at fault, which is always the chief issue).
Thank you for the help!