Dear all,
We are using DataStage 7.5 Server Edition. We can import ODBC table definition into DataStage.
However, when we try to click the View Data button from the ODBC stage, we get the following error message:
DSBrowser..ODBC_0.DSLink2: DSD.BCIOpenR call to OCONV failed.
Please help.
Thanks,
Gordon
Cannot view data from ODBC stage.
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 18
- Joined: Sun Sep 12, 2004 9:19 am
I don't know exactly what is causing it, but the reference to a call to OCONV might point to some data type conversion. What data types are you using in your columns, and can you remove the columns one-by-one until the error goes away in order to narrow down the problem?
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
What makes you think you can use OCONV in your SQL statements? Sure sounds from the error that that is what you are trying to do, and I would guess via custom sql. You'll have to wait until the data gets into your job and then, in a transformer, apply the OCONV (and any other DataStage specific) logic.
Can you post it? Your SQL, that is...
Can you post it? Your SQL, that is...
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
I think that the problem may, indeed, be a bug. OCONV could be being called by DSD.BCIOpenR (which opens the connection for reading). With the ODBC stage, if a data element is set to Date or Time, then an "implicit" conversion is performed - it's most likely that this uses Oconv (or Iconv, depending on direction).
Try reverting the data element to Default, see if that makes any difference. If it does, report the bug through your support provider, with a reproducible case, and let us know the outcome of your test.
Try reverting the data element to Default, see if that makes any difference. If it does, report the bug through your support provider, with a reproducible case, and let us know the outcome of your test.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Really?? Apologies then if that's the case, I assumed it was because of a derivation specifically added to the stage.ray.wurlod wrote:I think that the problem may, indeed, be a bug. OCONV could be being called by DSD.BCIOpenR (which opens the connection for reading). With the ODBC stage, if a data element is set to Date or Time, then an "implicit" conversion is performed - it's most likely that this uses Oconv (or Iconv, depending on direction).
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 18
- Joined: Sun Sep 12, 2004 9:19 am
Thanks, Roy! I've also heard that there is a bug relating to ODBC manipulation in DS 7.5 (for AIX). In fact, we couldn't even import table definition from ODBC source. Others told us that this issue could be fixed if we replace the DS 7.5 branded_odbc directory with DS 7.1/7.0 branded_odbc directory. So we did. However, we encountered the new problem as I described in my last post.ray.wurlod wrote:I think that the problem may, indeed, be a bug. OCONV could be being called by DSD.BCIOpenR (which opens the connection for reading). With the ODBC stage, if a data element is set to Date or Time, then an "implicit" conversion is performed - it's most likely that this uses Oconv (or Iconv, depending on direction).
Try reverting the data element to Default, see if that makes any difference. If it does, report the bug through your support provider, with a reproducible case, and let us know the outcome of your test.
Because this issue happened in the environment of our customer's, I will perform some test according to your instructions then let you know the result.
Thanks all again!
Gordon