Scenario:
ZABO 5.1.4
universe built on DB2 database
Problem:
When pulling in data from columns which are of data type date/timestamp ZABO will crash with an unhandled exception error c0000005
Remarks:
BO Full Client will work fine (using a regular *.key file) using the same universe objects, but ZABO will crash (so will BO Full Client when used in ZABO mode).
It looks like this problem has been partially resolved in BO v 5.1.6 (meaning pure ZABO works, but BO Full Client installation connecting via an *.rkey file in ZABO mode crashes after fetching some rows)
Example:
The following SQL will crash in BO ZABO 5.1.4 but run in DB2 client without a problem:
SELECT
TIMESTAMP (( Name_VW.OUT_DATE ), ( Name_VW.OUT_TIME ))
FROM Name_VW
Question:
Has anyone come across this? Has anyone a BO bug number or maybe even a CSP or other workarounds?
The answer to these questions is no. I know you will have looked at the various resolutions here but I don’t believe we have a Zabo specific resolution. Is your full client middleware identical to the Zabo middleware? Is the report saying ‘Analysing…’ or ‘Rows’ or even ‘Computing…’ when it crashes?
In BO ZABO 5.1.4 the data provider when being refreshed is analyzing (to be seen at the bottom of the window) and it shows fetching rows 50, but then it crashes.
Okay - how about playing with your array fetch size - just to see if a larger or small value can change anything? And the middleware question - is it all exactly the same?
Regarding the DB middleware:
When using ZABO 5.1.6 using the same *.rkey file the error does NOT occur, which leads me to believe it is not the DB middleware configuration on the WEBi/ZABO server.
Regarding array fetch size:
I will check with our BO infrastructure team
In the meantime:
Any other unlucky DB2 BO developer out there who can reproduce my scenario/problem?
In WEBi it works fine as well, but not in ZABO connecting via *.rkey file to the very same WEBi/ZABO server.
ZABO crashes after it analyzes and fetches approx 50 rows (looking at the status bar at the bottom) before it crashes, the array fetch size for the universe connection is set to 50… coincidence?
Our BO infrastructure team set the array fetch size to 1 for the universe connection.
Result:
ZABO analyzes then starts fetching about 584 rows, then it produces an error message: A Connection required to refresh this document is not available (DA0004 )
Our BO infrastructure team set the array fetch size to 500 for the universe connection.
Result: ZABO v 5.1.4 crashes with the c000005 unhandled exception error.
Still no cigar
Is there nobody out there in BO & DB2 land (known as never never land) who faces the same problem
I guess I will have to wait until we upgrade to BO 5.1.6 enterprise wide…
I’d say that you are timing out on the DB2 side and losing the connection. Can’t the DBAs trace this or look in a log file to see the tread and what it says? Also, is Resource Limit Facility (name?) turned on maybe? We have it set to 5 minutes of CPU time for all BO connections. In your case, ZABO and FC could be using different connections (definitely different correlation IDs).
OK Andreas - I’m not so sure my answer is helpful after reading back this post but it is possible in the DB2 world. IMHO you need to lighten up a bit on DB2 - it really is a good RDBMS; you just need to work with it more and learn its ways. As always, Designers are expected to be DBAs in some sense and should have the same tools as the DBAs to track down these things or at least be able to speak in their language when the need arises. I’m fortunate that in our shop, I came in as a DBA-type person and was able to learn a little and then a lot more when I got to deploy BO. Unfortunately, our main DBA, the wonderful woman who took me in and taught me so much, announced today that she is leaving for another state agency – ah yes, the wonderful decisions that upper mang. makes that leads to things that are counter productive. How can you let so much institutional/technical knowledge walk away? -
I have heard from some people that DB2 is better in performance than Oracle, but they also throw in that the usability does not match Oracles (for example: PL/SQL etc.).
At the place where I am working now we (non DBA’s) do not have any “nice” tools for DB2 such as SQL Station for Oracle etc. nor do I know of any.
I looked for good books regarding DB2 and I came up empty…
Nevertheless, I will get with the DB2 DBA’s and ask them to run a trace when I execute the query from within ZABO 5.1.4.
we have something called INSIGHT (MAINFRAME - CAPS of course) and then they added another tool last month that was even better but I have no input into what the MAINFRAME people do as it is a shared data center removed from campus. I have to log into the datacenter to do anything like that, which is a given but not great, not PC level tools like in Oracle.
Did you check the middleware? I forget what you are using but there are settings there if you are using DB2 Connect or Neon Shadow Direct or something else. Webi/ZABO could have different settings on the middleware than your F/C. I can give you details on either middeleware.
later - I’m pretty much out (like all this week in training)till next week - S
Update:
Our BO infrastsructure team said the DB middleware configuration is the same. So the solution is to go with BO v 5.1.6 and see if there will be any other bugs creeping up.
OK, we are on ZABO 5.1.6 and the same problem happens:
When running a simple SELECT query against a DB2 column of data type TIMESTAMP, ZABO crashes (although BO Full CLient works fine), WEBi will return the correct date portion, but will set the time portion to midnight
SELECT
TableName.LAST_UPDATE_TS
FROM
TableName
TableName.LAST_UPDATE_TS is of data type TIMESTAMP.
Is there anyone here using DB2 and columns of DATA type TIMESTAMP in a BO universe together with a WEBi/ZABO deployment? Anyone?
Can you get BO to verify that this is a bug? Maybe they have a workaround, a customer service pack or a forthcoming full service pack that will fix it.
We created a new alias name entry in the db2cli.ini file without the patch (this particular patch converted a DB2 Timestamp to a Date), changed the universe connection via BO supervisor to point to this db alias and everything is fine
(BOB member since 2002-06-20)
(BOB member since 2002-08-15)
