Multi-row SQLExtendedFetch Failed error

tet_hadavas

Active Member
Dear List,

Has anyone seen the following error message from jde.log?

3274/3460 ODBC_P1.C185
ODBC0000180 - Multi-row SQLExtendedFetch failed in Table(1st) F55Custom
Database Business Data_CRP

I received this error when running a UBE on the server and the fetch from the custom table failed. But the UBE completed without any error message if the job ran locally. It was able to fetch those 2 fields from the F55Custom table. I turned on the debug log and the jdedebug.log didn't show any errors. I don't think there's anything wrong with the table because I was able to insert, retrieve, and update those fields from an interactive application. Could it be the server ODBC? Any help would be greatly appreciated.

Thanks in advance for your help,
Tet Hadavas
OneWorld Xe, SP 17.1, Win 2000, SQL 7.0, MDAC 2.6
 
Hello Tet,

I'm experiencing the same issue:

5208/4916 ODBC_P1.C1601
ODB0000180 - Multi-row SQLExtendedFetch failed in Table(1st) Fxxxx
Database YYYYYY

OW Xe + SP24.

It sounds like an issue with ODBC at server level because the UBE works correctly on a fat-client.

Can you recall how did you fixed your issue ?

Thanks,

Carlo
 
This is a pretty general error. This could be caused by something as simple as disk space. If the tempdb cannot extend, it would cause this type of error. Can you provide a bit more detail?
 
Thank you for your answer Zuke,

I know "Multi-row SQLExtendedFetch failed" is pretty generic but:

* The error number (ODBC0000180) is exactly the same reported by Tet (ok, it's a 2002 thread).

* The system behaviour is exactly the same reported by Tet: everything ok using interactive application and error messages using UBE even fetching a small table with 2 records !

I don't have special setup for tempdb and disk space.

What should I check in your opinion ?

Thanks,

Carlo
 
A couple of things to check:-

- Are your tables in different datasources?
- Do you have OCM mapppings for the tables on the server you are running the report?
 
Hi Neal,

yes, the issue is with an additional datasource.
OCM mapping seems to me ok for both "system" and "Server Map".

Kind regards,

Carlo
 
The problem is the additional datasource(s).

There is a limit (can't remember the number off the top of my head) to the number of tables in different data sources that can be defined in a business view. Also, the limit doesn't seem to apply or is higher on a fat client as you may get the error on the web client or UBE but not on the fat client.

The only way around the problem is to have the tables in the same datasource, read the tables separately (don't use a business view) or collate the data from the different tables into a work table.

Cheers,

Neal
 
Thank you Neal for your help but my issue is not linked to BSVW objects with table join in different datasources.

I'm talking about a single table / single BSVW in a different datasource.

This is because the "main" datasource is on Oracle DB and the additional datasource is a Microsoft SQL Server.

I also would like to share the following test I did for debug purpose only:

* I did generate standard table F4008 in the "additional" (SQL Server) datasource.
* I did map OCM for my user (both system and "server map").
* P4008 interactive program (using F4008 table) is working perfectly.
* R40081 UBE program (using F4008 table) is working perfectly running locally on the fat client.
* R40081 UBE program (using F4008 table) is NOT WORKING on the server and I can see the following error in the log:

5208/4916 Tue Nov 14 14:29:56 2017 ODBC_P1.C1601
ODB0000180 - Multi-row SQLExtendedFetch failed in Table(1st) F4008
Database xxxxxxxxxx

I guess ODB0000180 stands for a specific error message while I know "Multi-row SQLExtendedFetch failed" is generic, but I was not able to find documentation on that.

Thanks,

Carlo
 
Hi Carlo,

You didn't make clear that the tables resided in different database types not just datasources.

I think you are stuck unless you investigate using a virtual table (search the forum, there are lots of posts about this) but it would mean changing the standard JDE objects (P4008, R40081) to use it.

Cheers,

Neal
 
Hi Neal,

the reason why I did test F4008 - P4008 - R40081 standard objects is indeed because I saw lots of posting talking about table definition / virtual tables.
Thus this is not my case (in my previous email I wrote "for debug purpose only").

Again: it's a test. I don't need indeed to change anything standard and the new datasource is storing for sure third party tables.

Ciao,

Carlo
 
Back
Top