Error: 01301 MFE IMO Client input message buffer overflow

[alisa.nua]

I got the error from my Gupta application and also from sqltalk.exe

Error: 01301 MFE IMO Client input message buffer overflow (MFE IMO)

For example, I execute one statement as in picture, the error will show below row number 12 of the result set
when actually the result set should return a total of 234 rows.

01301.PNG

Please help me with this.

[Charlie]

I've never run into that one.

What database product are you using ?

Is this a query that used to give no issues, and now suddenly is getting that error ?

Can you narrow down which column is giving the error? (I suspect it is "thai_name", but I prefer not assume.) To really pinpoint the column, run the query for each column, without the other columns involved.

[alisa.nua]

I'm running on Oracle database.

It gives very strange result, to describe :
After the first statement, I change it to

"Select * from app_message"

This statement return more rows instead of 12 in result set however still throw that error.
After that, I go back to the first statement, now the result is correct!!

The statement works fine on Toad and sql developer tools.
Please help.

[Jeff Luther]

Alisa -- have you looked at the TD book about connecting to [foreign] databases?
>> For earlier TDs it was called ccod.pdf

>> and I see they've renamed it in latest v6.3 test drive Books folder as: TD Connecting SQLWindows Objects to Databases.pdf

BTW, if you don't have TD set of PDF Books installed, I see there's a Books.zip link on this page for TD v5.2 SP2

Additionally, you wrote that if you

go back to the first statement, now the result is correct!!

That sounds like the message buffer is getting dynamically resized larger, which would explain why it's now large enough for your original fetch. I'd suggest looking at the PDF above, especially about message buffer settings and see if that provides a clue as to the problem.

Another 'flag' I see is that you are reporting this for (old) TD v5.1, and though you don't mention the version of Oracle you are using there may be an issue with the 5.1 router version. There's a link to the compatibility matrix that may be useful to as well.

I see that these versions of Oracle were officially 'supported' (i.e., tested) for TD v5.1: Oracle 9.2, Oracle 10g, Oracle 11g

[alisa.nua]

Jeff, I'm using Oracle 11g which is compatible according to the matrix.

Also, I checked my Sql.ini configuration in search order section, it's set as in the book.
[win32client.dll]
comdll=sqlora32
comdll=sqlodb32
comdll=sqlws32

Buffrow configuration is not an option for Oracle either, any other suggestions?

[Charlie]

Maybe irrelevant, but just in case:

What is the datatype and datalength of the thai_name column ?

And, how did the values get into the table ? With a Team Developer application ? Some other tool ?

[Jeff Luther]

Alisa -- Charlie had a good question, though it does not appear that thai_name is a LONG type. Based on the Reason info. below, what is the VARCHAR2() for example length of thai_name?

Another thing I see in the DBERROR Reason info. below is this sentence:

The server sends this error code back to the client, but does not send any of the data that caused the overflow.

This means the bottom thai_name value in your screen shot isn't what caused the error; it must be the next (non-fetched) value. Maybe with ID=16002 or 16003? I'd investigate that value, maybe fetch it by itself, to see if there's something wrong with the data? Just a guess...

Note too another sentence below:

The router and the server will continue to negotiate the buffer size...

That's consistent with your report that after running another query the first one now works. What happens if you run that first query 2 times? Does it also work the second time? If so, you can use the TD function SqlInMessage() to find out what that Input msg. buffer size had been set to. And call SqlSetInMessage ( hSql, nSize ) to dynamically set the buffer size to a higher value if need be.


One thing I use and refer to above, and you may not have used, is DBERROR.EXE utiltiy that comes with the Gupta product and gives you Reason/Remedy info. for many SQL errors. I just entered in 1301 add see quite a bit of Reason info:
Reason:

The server has detected a condition where the minimum amount of data to send to a client exceeds the buffer size for that data. The server sends this error code back to the client, but does not send any of the data that caused the overflow. The router at the client detects the condition and automatically attempts to correct for it by allocating a larger input message buffer. The router will automatically re-request the data be sent again using the new buffer size. The router and the server will continue to negotiate the buffer size until one of the following occurs: 1. The server is successfully able to transmit the data to theent, or 2. The server or the client router run out of available memorytheir respective machines. This error message should only appear at the server. It should not be seen at the client. The server and the client router perform the buffer size negotiation without the client's knowledge or participation. If the client app sees this error, it should be treated as a fatal error.

Remedy:

None. This message should only appear on the server. It should not be seen by the client application. [Jeff: not much help!]

[alisa.nua]

Charlie,
What is the datatype and data length of the thai_name column ?
- varchar2(250)
However, I don't think it's about the Thai character because even if I select column with English characters or numerals only,
it still gives me the overflow error.

And, how did the values get into the table ? With a Team Developer application ? Some other tool ?
- Could be from TD and import directly from other tools such as Toad, Oracle sql developer.

Jeff,
I also think it's about the buffer size but it should be automatically adjusted.
Earlier, I don't have this problem with Sqltalk when I use TD2.0.
Not sure if setting up the buffer size explicitly in the program is the way to do it.

Any ideas?

[Charlie]

Very wild and silly guess here from left field: unicode issue ?

[Jeff Luther]

unicode issue -- that would be my guess, too.

And Alisa, your comment that...

Earlier, I don't have this problem with Sqltalk when I use TD2.0.

is not a valid comparison. v2.0 was a VERY VERY long ago, some 12-15 years I would guess.

Additionally, v5.1 was the first Unicode version and there were a lot of issues fixed with the v5.2 release. You do at least have the latest SP release for 5.1 installed, right? That was SP6.

If you can get a trial version of v5.2 I would recommend you try that. 5.2 was a more stable release with many fixes. Your issue might be among them.

LAST -- as I implied by what I wrote, you could use Sal code to 'fix' (that is, workaround) your issue by finding out what the msg. buffer size got set to be and retry that. Did you do any of the testing I suggested? Running the same query 2 times to see if the second time worked?

Not sure if setting up the buffer size explicitly in the program is the way to do it.

Did you actually test this to find out? If not, what are you basing your conclusion on? Do be aware that TD has SqlInMessage() for a reason -- it isn't a bad thing or not the 'right way' to do it to change the buffer size. You may have to be in 'workaround' mode with v5.1, Alisa, and whatever you can do to fix or work around an issue, may not be 'the way' you would like to do it, but if it works...

[alisa.nua]

Charlie and Jeff,

The database character set is UTF8.
I've updated the SP6 for TD5.1, it doesn't solve the issue.

Now I'm updating SQLbase SP to the latest version.
If it still doesn't work, I will try the SqlInMessage() method.
I'll let you know the result.

Thanks for your kind help.

[alisa.nua]

Turns out, I just need to update the service pack.

[Charlie]

Excellent !