Error SQL Select

Primary tabs

.NET, Caché

Hello,

I am having a problem with SQL Select, the command in portal is OK, show all items, but when I use a CacheDataAdapter in VB .NET show the message 'Incorrect list format 0>=0'.  What could be this message? Because is the same SQL command.

Best Regards.

 

 

Replies

Hi Flavio,

I have recently started seeing the same error with our application. Were you ever able to solve or find the cause of the problem ??

Hello Robert,

I faced the same problem other day.
That was the query: "SELECT PROE,DESP,ID FROM ZVBMAPEAMENTO.SVINFOUVND WHERE JOB=1224 GROUP BY PROE"

Att. Flávio.

 I see just nothing in SQL that relates to the error message.
my only wild guess: some NULL value results confuse the VB end.
You could eventually bypass it using NVL() function

SELECT NVL(PROE,'*'),NVL(DESP,'*),NVL(ID,0) FROM ZVBMAPEAMENTO.SVINFOUVND
WHERE JOB=1224 GROUP BY PROE

What are the datatypes for the Properties in the SELECT list?  This error is coming from VB and most likely is caused by the data not matching up with the datatype def. of the Property.  Doing a quick google search for this error the first three hits were related to Streams.

When you run a query in the portal we do not do any type validation so if you have a MAXLEN on a %String set we are not going to check that, we assume it passed on data input.  External tools might be typed and can fall over if a string is longer than we said it was.

Limiting the fields in the SELECT list to figure out what data type is causing the problem is step 1.  Step 2 would be limiting the rows to figure out which one is producing the error and then looking at that data to see why it might be causing the problem.

Hello Brendan,

I faced the same problem other day.
That was the query: "SELECT PROE,DESP,ID FROM ZVBMAPEAMENTO.SVINFOUVND WHERE JOB=1224 GROUP BY PROE". All is %String.

Att. Flávio.

OK so I would try:  SELECT PROE,ID... and SELECT DESP,ID... to figure out which rows is causing the problem.

I would then look at how that %String is defined and then look at the data returned in the portal or shell to make sure the data matches how the property is defined. 

I have seen problems with some client side tools where they want to treat something we think is a simple VARCHAR as a CLOB.  If your %String has a large MAXLEN size then maybe this is what is going wrong?  To get to the bottom of that we would need to get an CacheODBC.log file ( or IRISODBC.log) and dig through the HEX dump.