Need help understanding ribo output
Bill McHugh
Shown below is part of the ribo output from two transactions. The database is the same in each case, as is the query run against it and the version of jConnect used (jConnect 5.5 build 25152/ebf 10106). In Case 1, the db engine is asa 6.0.2.2188. In Case 2, the db engine is asa 8.0.0.2269 (the latest ebf). Note the differences, which I've highlighted, in the ROWFMT Token (0xEE) sections.
Am I correct in interpreting this to mean that asa 6 is returning the column's value as an Integer (the correct data type) but asa 8 is returning the same value from the same column in the same row in the same database as a Numeric????
Could this be a bug in asa 8, or is there some legitimate reason why this would occur?
TIA for the help.
Bill
***Case 1 - ASA 6***
-----------------------------
Capture Record Header
Source [4]: REQUEST (0x00000001)
Length [4]: 42
PDU Header
TDS Packet Type [1]: BUF_NORMAL (0x0F)
Status [1]: BUFSTAT_EOM (0x01)
Length [2]: 42
Channel [2]: 0
Packet No. [1]: 0
Window [1]: 0
LANGUAGE Token (0x21); variable length.
Length [4]: 29
Status [1]: UNUSED (0x00)
Text Length [0]: [28]
Text [28]: "Select @@identity from dummy"
Capture Record Header
Source [4]: RESPONSE (0x00000002)
Length [4]: 45
PDU Header
TDS Packet Type [1]: BUF_RESPONSE (0x04)
Status [1]: BUFSTAT_EOM (0x01)
Length [2]: 45
Channel [2]: 0
Packet No. [1]: 0
Window [1]: 0
ROWFMT Token (0xEE);
Length [2]: 20
Number of Columns [2]: 1
Column 1
Name Length [1]: 10
Name [10]: "@@identity"
Status [1]: <unrecognized> (0x00)
User Type [4]: 7
Data Type [1]: INT4 <<<======
Length [0]: [4] <<<=========
Locale Length [1]: 0
ROW Token (0xD1); variable length.
Column 1
Length [0]: [4]
Row data [4]: 3 (0x00000003)
DONE Token (0xFD); fixed length.
Length [0]: [8]
Status [2]: DONE_COUNT (0x0010)
TranState [2]: TDS_TRAN_SUCCEED (0x0001)
Count [4]: 1
***Case 2 - ASA 8***
------------------------------
Capture Record Header
Source [4]: REQUEST (0x00000001)
Length [4]: 42
PDU Header
TDS Packet Type [1]: BUF_NORMAL (0x0F)
Status [1]: BUFSTAT_EOM (0x01)
Length [2]: 42
Channel [2]: 0
Packet No. [1]: 0
Window [1]: 0
LANGUAGE Token (0x21); variable length.
Length [4]: 29
Status [1]: UNUSED (0x00)
Text Length [0]: [28]
Text [28]: "Select @@identity from dummy"
Capture Record Header
Source [4]: RESPONSE (0x00000002)
Length [4]: 55
PDU Header
TDS Packet Type [1]: BUF_RESPONSE (0x04)
Status [1]: BUFSTAT_EOM (0x01)
Length [2]: 55
Channel [2]: 0
Packet No. [1]: 0
Window [1]: 0
ROWFMT Token (0xEE);
Length [2]: 23
Number of Columns [2]: 1
Column 1
Name Length [1]: 10
Name [10]: "@@identity"
Status [1]: <unrecognized> (0x00)
User Type [4]: 54
Data Type [1]: NUMN <<<=============
Length [1]: 10 <<<==================
Precision [1]: 0x14 <<<===============
Scale [1]: 0x00 <<<================
Locale Length [1]: 0
ROW Token (0xD1); variable length.
Column 1
Length [1]: 10
Row data [10]: 4
DONE Token (0xFD); fixed length.
Length [0]: [8]
Status [2]: DONE_COUNT (0x0010)
TranState [2]: TDS_TRAN_SUCCEED (0x0001)
Count [4]: 1
Chris Keating
/ck
"Bill McHugh" <WMcHugh@remove_this_for_email.FutureRes.com> wrote in message
news:nLgzK7q...@forums.sybase.com...
Bill McHugh
"Chris Keating" <nospam_...@iAnywhere.com> wrote in message news:aOs80Qr...@forums.sybase.com...
> IDENTITY is a BigInt in ASA7 and later.
I'm trying to figure out where to go next with this problem (my choices are to stay here with it, to go to the jConnect forum, or to go the powerj.datawindow forum - it's causing the java datawindow to throw an exception). Questions:
1. The ribo trace in Case 2 (ASA8) suggests that @@identity is being returned as a Numeric, not a BigInt. Note the length, precision, and scale. Does this point to a problem with the asa 8 engine, the jConnect driver, or the code that's using the jConnect driver? (I'm not well versed enough in ribo traces to know whether it is telling me what asa is putting out or how jConnect is interpreting it.)
2. The only reference I could find on this behavior change in the docs was "ODBC SQLDescribeCol behavior A SQLDescribeCol call on the @@identity field now returns SQL_BIGINT. In earlier versions, it returned SQL_INTEGER.", but jConnect doesn't use ODBC, does it? (Again, please excuse my ignorance here.)
3. As a workaround, is there some way to force the pre-asa7 behavior so identity will return an integer?
Chris Keating
I executed "select @@identity from dummy"
/ck
"Chris Keating" <kea...@iAnywhereSolutions.com> wrote in message
news:oXSb64x...@forums.sybase.com...
> When I execute "expr() unsigned bigint" the graphical plan shows that the
> column is "expr() unsigned bigint". Sybase Central 4.1.0 is using jConnect
> 5.5
>
> /ck
>
> "Bill McHugh" <WMcHugh@remove_this_for_email.FutureRes.com> wrote in
message
> news:t$8mT6r2...@forums.sybase.com...
Chris Keating
column is "expr() unsigned bigint". Sybase Central 4.1.0 is using jConnect
5.5
/ck
"Bill McHugh" <WMcHugh@remove_this_for_email.FutureRes.com> wrote in message
news:t$8mT6r2...@forums.sybase.com...
Chris Keating
to your identity column?
/ck
"Bill McHugh" <WMcHugh@remove_this_for_email.FutureRes.com> wrote in message
news:t$8mT6r2...@forums.sybase.com...
Bill McHugh
> What exception is being thrown? What datawindow column type have you mapped
> to your identity column?
Chris, I posted the exception details earlier in "jConnect/metadata problem in 8.0 engine?" on 3/31/02, which deals with the same problem, but here it is again. The error is being thrown by a java datawindow method before my own code (getItemNumber) completes. The ribo log is from this same event.
The identity column is a primary key with a user-defined data type (domain) which has a built-in type of integer and a default of autoincrement. DataWindow Builder (7.0.3 build 10047) shows the column as an int in the query painter and brings the column in as a "long" in the dw painter, all of which worked just fine before asa 8.0.
Can you figure out which of the Sybase components (PowerJ datawindow, JConnect, or ASA) is at fault?
--------------------------------------------------------
A PowerJ form that was working perfectly previously is now throwing the error shown below when I try to retrieve an identity column's value in the updateEnd event after upgrading to ASA 8.0 (8.0.0.2065). PJ version remains at 3.6.1C1, build 4014. The updateEnd event code is shown first, then the error log. The line of code that triggers the error (JIF_Region_List.java:587) is this one:
regionID = (int)jdw_1.getItemNumber(jdw_1.getRow(), region_id);
and it returns a zero value:
JIF_Region_List.jdw_1_updateEnd regionID = 0
but the new (identity) value for region_id is in fact properly created, as a later attempt to retrieve it suceeds.
updateEnd
---------------
private void jdw_1_updateEnd( powersoft.datawindow.event.UpdateEvent event )
{
regionID = (int)jdw_1.getItemNumber(jdw_1.getRow(), region_id);
System.err.println("JIF_Region_List.jdw_1_updateEnd regionID = "+regionID);
SwingUtilities.invokeLater(reinitializeDataWindow);
}
Error log
------------
ERROR : BaseValue : Invalid method called.
ERROR : This implementation should never have been called
ERROR : The overridden implementation in DataValueXxx...
ERROR : should have been called instead
ERROR : The type of this DataValue is : DECIMAL
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:993)
at powersoft.datawindow.DataValue.stb(Unknown Source)
at powersoft.datawindow.DataValue.getValueInt(Unknown Source)
at powersoft.datawindow.DWConsole.getItemDouble(Unknown Source)
at powersoft.datawindow.DWConsole.getItemNumber(Unknown Source)
at powersoft.datawindow.JDataWindowChild.getItemNumber(JDataWindowChild.java)
at powersoft.datawindow.JDataWindowChild.getItemNumber(JDataWindowChild.java)
at JIF_Region_List.jdw_1_updateEnd(JIF_Region_List.java:587)
at JIF_Region_List.updateEnd(JIF_Region_List.java:365)
at powersoft.datawindow.DWConsole.xs(Unknown Source)
at powersoft.datawindow.DWConsole.dwNotify(Unknown Source)
at powersoft.datawindow.DWConsole.dwNotify(Unknown Source)
at powersoft.datawindow.DWObject.dwNotify(Unknown Source)
at powersoft.datawindow.DWDBUpdater.tableUpdate(Unknown Source)
at powersoft.datawindow.DWObject.tableUpdate(Unknown Source)
at powersoft.datawindow.DataWindowServer.tableUpdate(Unknown Source)
at powersoft.datawindow.DWConsole.update(Unknown Source)
at powersoft.datawindow.JDataWindowChild.update(JDataWindowChild.java)
at powersoft.datawindow.JDataWindowChild.update(JDataWindowChild.java)
at powersoft.powerj.ui.JDataNavigator.performDefaultAction(JDataNavigator.java:989)
at powersoft.powerj.ui.JDataNavigator.actionPerformed(JDataNavigator.java:1040)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1450)
at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1504)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:378)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:250)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:216)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:230)
at java.awt.Component.processMouseEvent(Component.java:3715)
at java.awt.Component.processEvent(Component.java:3544)
at java.awt.Container.processEvent(Container.java:1164)
at java.awt.Component.dispatchEventImpl(Component.java:2593)
at java.awt.Container.dispatchEventImpl(Container.java:1213)
at java.awt.Component.dispatchEvent(Component.java:2497)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
at java.awt.Container.dispatchEventImpl(Container.java:1200)
at java.awt.Window.dispatchEventImpl(Window.java:926)
at java.awt.Component.dispatchEvent(Component.java:2497)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:85)
Bill McHugh
1. The ASA7 trace is consistent with what Chris says about the datatype of @@identity being a bigint. But why does the ASA8 engine return NUMN under the same circumstances (see prior posts)?
2. Does this test, along with the ASA8 test, suggest the problem is in the datawindow code? Or could it be in JConnect or the ASA8 engine?
ROWFMT Token (0xEE);
Length [2]: 21
Number of Columns [2]: 1
Column 1
Name Length [1]: 10
Name [10]: "@@identity"
Status [1]: <unrecognized> (0x00)
User Type [4]: 13
Data Type [1]: INTN
Length [1]: 8
Locale Length [1]: 0
ERROR : BaseValue : Invalid method called.
ERROR : This implementation should never have been called
ERROR : The overridden implementation in DataValueXxx...
ERROR : should have been called instead
ERROR : The type of this DataValue is : BIGINT
Bill McHugh
an INTN under exactly the same circumstances with exactly the same database?
I really need some help in figuring out which of the three Sybase components
involved (PowerJ java datawindow, jConnect 5.5, ASA8) is causing the
problem. Thanks.
Bill
"Bill McHugh" <WMcHugh@remove_this_for_email.FutureRes.com> wrote in message
news:AnfUMy2...@forums.sybase.com...