 |
Forums |
Admin  Start New Thread
By: Praveen Devarao
 RE: NoMethodError ibm_db_adapter:912 'columns [ reply ]
2008-08-27 11:49
|
Hi Frank,
I talked to the CLI people and got a good news that they too had faced a problem like this, but in there case it was not the zOS as server but VM/VSE. I came to know that this kind of scenario will occur when the DB2 server is not of the required level. DB2 zOS server prior to V8 used to return the result set, when issued SQLColumns, with numbers for the column and not the column names. Which is the scenario that you are facing.
Given that your server is DB2 UDB zSeries V8 Compatibility Mode, could you check with your dbadmins if they have followed all the necessary steps, like applying the proper APAR's, while bringing the system to compatibility mode. Might be they have missed out on some step while migrating the production server. I am providing couple of links below , which talk about the migration of the DB2 server from v7 to v8, for your reference. Check the first link below, it talks about few APAR's which have to be applied.(One thing that I could make a note of from the link was, after applying the necessary APAR you should start the V7 subsystem before any attempts to start V8. Given that the problem is in the production server could be this step was missed).
http://it.toolbox.com/blogs/db2zos/db2-for-zos-version-8-migration-preplanning-5166
http://it.toolbox.com/blogs/db2zos/whats-your-db2-for-zos-v8-migration-strategy-8735
Also are both your servers being migrated to the same level (I mean, are they being migrated to the same fixpak level).
Let me know if this helps you.
Thanks and Regards
Praveen
|
By: Frank Kuepper
RE: NoMethodError ibm_db_adapter:912 'columns [ reply ]
2008-08-26 19:13
|
Hi Praveen,
silly me - of course, I should have provided the details you're asking for, right at the beginning :-)
The client machine, where the Rails application runs on, is the same one for all environments and runs with Instant Rails 2.0.2 under Windows XP.
The database connection for all environments uses an alias.
I'll have a look into the cli configuration and the alias configurations to see, if I can find some hints there.
Greetings,
Frank
|
By: Praveen Devarao
RE: NoMethodError ibm_db_adapter:912 'columns [ reply ]
2008-08-25 16:47
|
Hi Frank,
Yes, I am able to know about the problem. That was really good and helpful that you provided with the CLI trace. I am also not able to find out in which conditions will this(seeing number for the column names) happen. As going by the CLI documentation for SQLColumns() function the result set should have been returned with names of the column, as in case of your development environment.
The solution that you are suggesting is fine. However we have to look into various other aspects, ensuring that nothing else will be broken (Theoretically, this shouldn't break anything :-) ). For this I am trying to get information on which conditions does this scenario occurs. I will get in touch with the CLI people here in IBM and will keep you updated on my findings.
By the way can you provide with some more details. Which platform is your client on? Also are you using the same client machine to connect to your Production as well as your Development server(host)? If the client machines are different, can you check the cli configuration (Like the version of CLI etc) on both the machines, that is if they are same? At the mean time I will try to get information on the kind of scenario that you are facing.
Thanks
Praveen
|
By: Frank Kuepper
RE: NoMethodError ibm_db_adapter:912 'columns [ reply ]
2008-08-23 08:36
|
Hi Praveen,
sorry for the delayed answer, but I've been on summer holidays :-)
The problem is not, that SQLColumns doesn't return nothing at all, but that it returns something odd. Here's a short bite from the clitrace in development environment, where everything works fine:
SQLColumns( hStmt=1:1, pszCatalogName=<NULL pointer>, sCatalogNameByteCount=-3, pszSchemaName="ENTW", sSchemaNameByteCount=-3, pszTableName="V0AS0416", sTableNameByteCount=-3, pszColumnName=<NULL pointer>, sColumnNameByteCount=-3 )
---> Time elapsed - +7,690000E-004 seconds
( StmtOut="CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)" )
( Row=1, iPar=1, fCType=SQL_C_CHAR, rgbValue=<NULL pointer>, pcbValue=-1, piIndicatorPtr=-1 )
( Row=1, iPar=2, fCType=SQL_C_CHAR, rgbValue="ENTW" - x'454E5457', pcbValue=4, piIndicatorPtr=4 )
( Row=1, iPar=3, fCType=SQL_C_CHAR, rgbValue="V0AS0416" - x'5630415330343136', pcbValue=8, piIndicatorPtr=8 )
( Row=1, iPar=4, fCType=SQL_C_CHAR, rgbValue=<NULL pointer>, pcbValue=-1, piIndicatorPtr=-1 )
( Row=1, iPar=5, fCType=SQL_C_CHAR, rgbValue="DATATYPE='ODBC';GRAPHIC=1;REPORTUDTS=0;LUWUDT=1;DB2LUW=1;" - x'44415441545950453D274F444243273B475241504849433D313B5245504F5254554454533D303B4C55575544543D313B4442324C55573D313B', pcbValue=57, piIndicatorPtr=57 )
( return=0 )
( Requested Cursor Attributes=0 )
( Reply Cursor Attributes=524298 )
( Actual Cursor Attributes=524298 )
SQLColumns( )
<--- SQL_SUCCESS Time elapsed - +1,656880E-001 seconds
SQLNumResultCols( hStmt=1:1, pcCol=&023d7b08 )
---> Time elapsed - +7,270000E-004 seconds
SQLNumResultCols( pcCol=18 )
<--- SQL_SUCCESS Time elapsed - +4,232000E-003 seconds
SQLDescribeCol( hStmt=1:1, sCol=1, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&04d70f7c, puiColDef=&04d70f80, psScale=&04d70f84, psNullable=&04d70f86 )
---> Time elapsed - +6,800000E-004 seconds
SQLDescribeCol( pszColName="TABLE_CAT", psColNameCharLen=9, psSQLType=SQL_VARCHAR, pcbColDef=128, psScale=0, psNullable=SQL_NULLABLE )
<--- SQL_SUCCESS Time elapsed - +1,247600E-002 seconds
SQLDescribeCol( hStmt=1:1, sCol=2, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&04d70f98, puiColDef=&04d70f9c, psScale=&04d70fa0, psNullable=&04d70fa2 )
---> Time elapsed - +7,020000E-004 seconds
SQLDescribeCol( pszColName="TABLE_SCHEM", psColNameCharLen=11, psSQLType=SQL_VARCHAR, pcbColDef=128, psScale=0, psNullable=SQL_NULLABLE )
<--- SQL_SUCCESS Time elapsed - +1,208600E-002 seconds
SQLDescribeCol( hStmt=1:1, sCol=3, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&04d70fb4, puiColDef=&04d70fb8, psScale=&04d70fbc, psNullable=&04d70fbe )
---> Time elapsed - +6,770000E-004 seconds
SQLDescribeCol( pszColName="TABLE_NAME", psColNameCharLen=10, psSQLType=SQL_VARCHAR, pcbColDef=128, psScale=0, psNullable=SQL_NO_NULLS )
<--- SQL_SUCCESS Time elapsed - +1,395200E-002 seconds
Whereas in production, SQLColumns yields
SQLColumns( hStmt=1:1, pszCatalogName=<NULL pointer>, sCatalogNameByteCount=-3, pszSchemaName="PROD", sSchemaNameByteCount=-3, pszTableName="V0AS0416", sTableNameByteCount=-3, pszColumnName=<NULL pointer>, sColumnNameByteCount=-3 )
---> Time elapsed - +5,900000E-004 seconds
( StmtOut="CALL SYSIBM.SQLCOLUMNS(?,?,?,?,?)" )
( Row=1, iPar=1, fCType=SQL_C_CHAR, rgbValue=<NULL pointer>, pcbValue=-1, piIndicatorPtr=-1 )
( Row=1, iPar=2, fCType=SQL_C_CHAR, rgbValue="PROD" - x'50524F44', pcbValue=4, piIndicatorPtr=4 )
( Row=1, iPar=3, fCType=SQL_C_CHAR, rgbValue="V0AS0416" - x'5630415330343136', pcbValue=8, piIndicatorPtr=8 )
( Row=1, iPar=4, fCType=SQL_C_CHAR, rgbValue=<NULL pointer>, pcbValue=-1, piIndicatorPtr=-1 )
( Row=1, iPar=5, fCType=SQL_C_CHAR, rgbValue="DATATYPE='ODBC';GRAPHIC=1;REPORTUDTS=0;LUWUDT=1;DB2LUW=1;" - x'44415441545950453D274F444243273B475241504849433D313B5245504F5254554454533D303B4C55575544543D313B4442324C55573D313B', pcbValue=57, piIndicatorPtr=57 )
( return=0 )
( Requested Cursor Attributes=0 )
( Reply Cursor Attributes=524298 )
( Actual Cursor Attributes=524298 )
SQLColumns( )
<--- SQL_SUCCESS Time elapsed - +5,434500E-002 seconds
SQLNumResultCols( hStmt=1:1, pcCol=&023d7b08 )
---> Time elapsed - +6,210000E-004 seconds
SQLNumResultCols( pcCol=18 )
<--- SQL_SUCCESS Time elapsed - +3,707000E-003 seconds
SQLDescribeCol( hStmt=1:1, sCol=1, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&0507ee0c, puiColDef=&0507ee10, psScale=&0507ee14, psNullable=&0507ee16 )
---> Time elapsed - +6,150000E-004 seconds
SQLDescribeCol( pszColName="1", psColNameCharLen=1, psSQLType=SQL_VARCHAR, pcbColDef=128, psScale=0, psNullable=SQL_NULLABLE )
<--- SQL_SUCCESS Time elapsed - +1,068700E-002 seconds
SQLDescribeCol( hStmt=1:1, sCol=2, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&0507ee28, puiColDef=&0507ee2c, psScale=&0507ee30, psNullable=&0507ee32 )
---> Time elapsed - +6,010000E-004 seconds
SQLDescribeCol( pszColName="2", psColNameCharLen=1, psSQLType=SQL_VARCHAR, pcbColDef=128, psScale=0, psNullable=SQL_NULLABLE )
<--- SQL_SUCCESS Time elapsed - +1,401500E-002 seconds
SQLDescribeCol( hStmt=1:1, sCol=3, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&0507ee44, puiColDef=&0507ee48, psScale=&0507ee4c, psNullable=&0507ee4e )
---> Time elapsed - +6,110000E-004 seconds
SQLDescribeCol( pszColName="3", psColNameCharLen=1, psSQLType=SQL_VARCHAR, pcbColDef=128, psScale=0, psNullable=SQL_NO_NULLS )
<--- SQL_SUCCESS Time elapsed - +1,102100E-002 seconds
SQLDescribeCol( hStmt=1:1, sCol=4, pszColName=&023d7900, sColNameMaxByteLen=512, psColNameCharLen=&023d7b0c, psSQLType=&0507ee60, puiColDef=&0507ee64, psScale=&0507ee68, psNullable=&0507ee6a )
---> Time elapsed - +6,310000E-004 seconds
Notice the odd pszColName-Values ("1", "2" and so on). So as I said before: If I patch ibm_db_adapter.rb exchanging the column-lookup to using name or number (for example col["column_name"] || col["4"] instead of col["column_name"]), access is successful.
It's only that nobody was able to explain to me yet, where the oddness with pszColName results from. So I'm not sure, if my applied hack is a valid and lasting solution.
Greetings,
Frank
|
By: Frank Kuepper
NoMethodError ibm_db_adapter:912 'columns' [ reply ]
2008-07-14 08:43
|
Hi,
I'm not quite sure, if it's a bug or a feature or if it's simply me working on an unsupported DB2 version ;-)
I use the ibm_db gem version 0.9.4 connecting to two different databases on two different hosts, both of them DB2 UDB zSeries V8 Compatibility Mode, one for development and test and one for production.
On one of them (development and test) the application is working fine, on the other one (production) it throws a NoMethodError:
"You have a nil object when you didn't expect it!
The error occurred while evaluating nil.downcase"
in ibm_db_adapter.rb:912:in `columns'
As our db-admins are not too helpful, I digged into it with a cli-trace and found out, that on the faulty host, the result of SQLColumns didn't have the columns, that the ibm_db_adapter expected ("column_name", "type_name" etc.), but rather numbers ("1", "2" etc.).
Well, for me a quick and dirty hack in ibm_db_adapter.rb exchanging the column-lookup to using name or number (for example col["column_name"] || col["4"] instead of col["column_name"]) did the trick. But it feels a little bit uncomfortable ;-)
Anyone able to shed some light on why this is so and if my hack is safe enough for further use?
Thanks,
Frank
|
|
|
