Greetings.
Can somebody help?
I've done this and that, but can´t stop getting "incompatible datatype parameter" messages:
ASSIGN pQuery = SUBSTITUTE("Fecha >= &1 and Fecha <= &2",
DATE(MONTH(date1), DAY(date1), YEAR(date1) ), DATE(MONTH(date2), DAY(date2), YEAR(date3) )).
/* also, done this */ ASSIGN
pQuery = SUBSTITUTE("statusEtiqueta <> ' ' and Fecha >= &1/&2/&3 and Fecha <= &4/&5/&6",
STRING(DAY(fDesde)), STRING(MONTH(fDesde)), STRING(YEAR(fDesde)), STRING(DAY(fHasta)), STRING(MONTH(fHasta)), STRING(YEAR(fHasta))).
after that I call a routine that instantiates the BE somewhere inside the appserver like this:
myCaso:ReadCasoPaq(pQuery, OUTPUT DATASET dsCasoPaquete).
but on calling proc I catch a lang.syserror: (223) incompatible data types
Any help will be appreciated>for some strange reason progress likes the dates to be MDY ;) - See more at: community.progress.com/.../76234
Marian
Hi Marian, this is a dangerous trap... you should use the QUOTER function for date, datetime and decimal data types in order to accomodate this kind of problem. I mean, when a date appears between double quotes in a dyn query, the the ABL knows how to take your session non american culture (date format, numeric decimal point) into account
Note QUOTER was introduced a long time ago (V9 days) to solve this issue.
QUOTER also takes care of the unknown value. (returns unquoted question mark character in that case)
Combined with the good SUBSTITUTE function, the solution becomes:
pQuery = SUBSTITUTE("Fecha >= &1 and Fecha <= &2", QUOTER(date1), QUOTER(date2)).
where date1 and date2 are of DATE data type. I mean, if the point of your get4GLDate() is to return a date in MDY, then I believe this is a wrong track.
HTH
Kind regards
/Sebastien L.
and pQuery is defined as?
Is type Character....
The program used to work this way....
pQuery = "StatusEtiqueta = ' '" .
and it was enhanced to
pQuery = "StatusEtiqueta = ' ' and Fecha.... "
and that's the trouble, (I use the dmy format) I don't know how to include a date datatype in the string to be passed to the procedure that ultimatelly will be calling the method inside the class of the BE, which in turn calls
SUPER:ReadData(filter).
Didn't understand myself.... Let's see... I have this chain of callings.
A .w form, has this calling:
RUN procs\ventas\apSuc0301.p ON hServer
(pQuery, OUTPUT DATASET dsCasoPaquete ) .
and this is apSuc0301.p
BLOCK-LEVEL ON ERROR UNDO, THROW.
USING procs.ventas.dsCasoPaq FROM PROPATH.
{procs\ventas\inc\dscasopaq.i}
DEFINE INPUT PARAMETER pQuery AS CHARACTER NO-UNDO.
DEFINE OUTPUT PARAMETER DATASET FOR dsCasoPaquete.
DEFINE VARIABLE myCaso AS dsCasoPaq NO-UNDO.
myCaso = NEW dsCasoPaq().
myCaso:ReadCasoPaq(pQuery, OUTPUT DATASET dsCasoPaquete).
DELETE OBJECT myCaso.
-----
dsCasoPaq() is the BE as generated by wizard.
Your client and server date formats do not match (session:date-format).
You have already 'corrupted' your date value on the client side by putting it in a character. You have several options:
1. attempt to parse the date value out of the character on the server (mess)
2. pass client date-format to server and set server date format to client date-format (not bad)
3. pass individual query values to the server and construct the query string on the server - you should really be doing this anyway - allowing a query phrase from the client to be used on the server without any other validation opens your server up for all sorts of nastiness.
I'll do as you told..., but mean while....
How can I construct the char query var that ultimatelly will be sent to business entity? Neverteless I have to put in a char var the "dynamic query" somehere ...
(I've just added -d dmy to the asbroker1's agent startup parameter... how can I know if it is doing trouble?)
(of course restarted broker)
Either make sure you have proper locale agnostic round trip conversions for all data types. Or define a temp-table with field name and field value - in which you have a separate field for each 'difficult' data-type. You could if you wanted to serialize this as xml / json and reconstruct it on the server side.
The problem is not sending the data to the server... I've already checked that all stuff is arrived ok....
the problem is defining/constructing the string that will hold the where clause to the final FOR EACH that will be doing the BE.
the problem is the
SUPER:READDATA(... string containing the where part of query ...)
It's the fill clause/condition for DATASETS that I cannot assemble...
Sorry not being able to express myself....
pQuery = SUBSTITUTE("Fecha >= &1 and Fecha <= &2",
get4GLDate(date1), get4GLDate(date2)).
getDate returns character (dateIn as date):
return substitute('&1/&2/&3', MONTH(dateIn), DAY(dateIn), YEAR(dateIn)).
end.
for some strange reason progress likes the dates to be MDY ;)>for some strange reason progress likes the dates to be MDY ;) - See more at: community.progress.com/.../76234
Marian
Hi Marian, this is a dangerous trap... you should use the QUOTER function for date, datetime and decimal data types in order to accomodate this kind of problem. I mean, when a date appears between double quotes in a dyn query, the the ABL knows how to take your session non american culture (date format, numeric decimal point) into account
Note QUOTER was introduced a long time ago (V9 days) to solve this issue.
QUOTER also takes care of the unknown value. (returns unquoted question mark character in that case)
Combined with the good SUBSTITUTE function, the solution becomes:
pQuery = SUBSTITUTE("Fecha >= &1 and Fecha <= &2", QUOTER(date1), QUOTER(date2)).
where date1 and date2 are of DATE data type. I mean, if the point of your get4GLDate() is to return a date in MDY, then I believe this is a wrong track.
HTH
Kind regards
/Sebastien L.