0

I have a very strange situation with a couple of procedures in my project. Both do the same (see below) but on different tables, so I'll explain the issue (same in both procedures).

I have a table hosting hundreds of labels that need to be returned to a client. The response is always sent as TEXT. Initially, the procedure would select from the relevant table, perform the required concatenation, and send the string back.

I made a simple (or so I thought) change that would store the result into a DIGEST table. So, when the same function is invoked the second time, it would first check if there is an applicable response available within the digest table and, if yes, just return the response. If there is no matching entry in the digest, build the response, store it within the digest table (for next invocation) and return the built response.

The functions work perfectly if I always build (concatenate) the response and return it. If, on the other hand, I extract the response from the digest table, I get the error Error Code: 1366. Incorrect string value: '\xF0K\xF59{z...'.

I checked the contents of the digest table and it looks OK.

Any idea where the issue might come from?

Thanks in advance for any suggestion.

FDavidov
  • 3,505
  • 6
  • 23
  • 59
  • I should add that I'm using exactly the same mechanism in other 6 functions and it works perfectly well (with excellent performance!). – FDavidov May 29 '16 at 16:49
  • This may help [you](http://stackoverflow.com/a/1168099/2451726) – Arulkumar May 29 '16 at 18:13
  • Thank you @Arulkumar, but it does not. In all, I have about 8 functions that perform identical logic except that they work on different source tables. The only difference between the two PROBLEMATIC functions and the rest is the size of the returned data (biggest in the problematic function). Moreover, the issue pops when the retrieved strings are in plane English (i.e. UTFx not really used). – FDavidov May 30 '16 at 04:38

1 Answers1

0

It turned out that I was lucky and hit a known bug (of the version I'm using). I resolved it by chopping a long CLOB into a series of VARCHARs (also changed the type of the table's column). Yes, I know.. this is not the best solution in terms of performance, but at this stage of the project I'll not even think of upgrading to a newer version of the database.

FDavidov
  • 3,505
  • 6
  • 23
  • 59