CALCDATE Multilanguage Problem

Betrachter84

Hi

I have a problem concerning the function Calcdate and multilingual dateformula variables.

There is a editable textbox on the request form of a report.

- SourceExpr: PeriodLength
- Data type of the variable PeriodLength: DateFormula
- String entered in textbox on report start: 2Y if im running it in english, 2J if im running it in german

Later i use the PeriodLength variable in a CALCDATE function like this:

CALCDATE('<+1D->' + FORMAT(PeriodLength),WORKDATE);

If i'm running the report with application lanquage english, there is no problem. If i'm running it in any other language a runtime error occurs reporting, that the date expression i entered '2J' was not valid. Omitting the string '<+1D->' solves the problem even in german, but then the result of the CALCDATE function ain't the same anymore...

I tried a lot allready like using PeriodLength without Format(), with <> around it. Nothing worked.

Is there maybe a trick i don't know? i'd be very grateful if someone could help me out with taht problem.
Thanks in advance!

jannestig

Not a developer but these post addressed the issues of changing language and solved it

viewtopic.php?f=23&t=31755&hilit=date+language

viewtopic.php?f=23&t=35713&hilit=date+language

Main issue seemed to be

kine wrote:

mb6606 wrote:

Do not forget to add '<' and '>' around the string before passing it to the CALCDATE, else you will have problems when you switch client into another language.

Betrachter84

it's not exactly the same.

my problem concerns the usability of the hard-coded string '<+1D->' and the dateformula variable PeriodLength in the same CALCDATE function...

might storing the string '<+1D->' in another dateformula variable be a possibility?

Miklos_Hollender

Store it simply in a multilanguage TextConstant, ENU: +1D, DEU: +1T etc. (I think the <, > and - are not really necessary).

Also, if you are trying summarize posts until the end of the year or two years with a 2Y+1D trick, that's not really a good way to do it, you should rather be using CLOSINGDATE((CALCDATE...)) (look it up in the C/SIDE help). CLOSINGDATE(today) is that "magic" date that's later than today but earlier than tomorrow.

matttrax

Or don't hard code it. Store the value in a setup form somewhere.

Betrachter84

Miklos Hollender wrote:

Store it simply in a multilanguage TextConstant, ENU: +1D, DEU: +1T etc. (I think the <, > and - are not really necessary).

Thaks, that was the solution.
A "language-neutral" DateFormula variable a string in any language different from english in the same calcdate expression was the problem. with two multilanguage strings it works.