[Rocket U2][U2ODBC][2300701]Error ID: 46 State: S1000; U2 Database code: 930122; Msg: [U2][SQL Client][UNIVERSE]UniVerse/SQL: Row length exceeds buffer size

I've overcome most of the issues discussed earlier in the following two threads.  The background there may help in addressing this question.
Rocket U2 | UniVerse & UniData

Rocketsoftware		remove preview
Rocket U2 | UniVerse & UniData Rocket U2][U2ODBC][2300701]Error ID: 46 Severity: ERROR Facility: DBCAPERR - UCI Error. Func: SQLFetch(XIO); State: S1000; U2 Database code: 20085; Msg: [U2] View this on Rocketsoftware >

Rocket U2 | UniVerse & UniData

Rocketsoftware		remove preview
Rocket U2 | UniVerse & UniData I'm using the latest U2 64-+Bit ODBC Driver Version 7.241.02.9004.The ODBC Connection tests successfully and works perfectly in applications that use ODBC, such View this on Rocketsoftware >

The current error is the subject error message, which I am receiving when I attempt to query certain "tables" from Microsoft SQL Server Management Studio where the Universe U2 system is configured as a linked server via OLEDB/ODBC.

For example, on one table, I can execute the following successfully:

select top (100) *
from [my tablespace name]...[my table name];

but if I try to do more than 100 rows, it fails with error above.
If I try to do a count, it fails with error above.
if I try to just select one column, or try to add any type of where clause, it fails with error abovev.

Have you tried increasing the value of MAXFETCHBUFF defined in the uci.config file.  It defaults to 8192. Try Increasing it to a large enough value is necessary to eliminate the error. The UCI config Editor gives you a nice interface into editing the file.

Awesome, thanks Jonathan!

I started by doubling it, then x4, but was still having issues.  So I just went x64 and set it to 524288 and was able to run a select * on all rows and columns in the table in question. 

Granted, it took 20minutes to return just 52k records, but at least I can get them again.

Karl,

Unless the file is massive, 52K records n 20 minutes seems a bit too long. As a suggestion, check the multivalues are associated as this cold have a significant effect if there are  a very large number involved. Otherwise filter out the records returned and put them in a  separate small file by themselveds is the time still around 20 minutes?

This should separate out the file size and record lock contention as factors - barring heavy use of irtual logoc and separate file rtanslations.

Regards

JJ