Space in date format causes error

Troubles_In_Paradise

Hi guys!
Yesterday we crashed into a strange error.
I'll explain to you with an example:
Create 2 simple table:

1.
  Table Name: Header
  Fields: Code [Code10], Date [Date]
  PK: Code,Date
2.
  Table Name: Lines
  Fields: Code [Code10], Date [Date], Number [Integer], Data [Text30]
  PK: Code,Date,Number

For 1 Header could be many Lines.
Now create 2 pages. 1 Document Page based on the table Header and one ListPart based on the Lines Table.
In the Document Page call the ListPart with the standard property SubFormLink:

Code=FIELD(Code),Date=FIELD(Date)

And that's it...
Check to have english format for dates and numbers (see attachment 1).

if you run the page no problem...
now change the format for dates and numbers to slovak

restart RTC and run again page
the page is executed with the error:


the system try to make a filter on the field Date of the lines table with the value '11. '.
going deeper I found that if you remove the space as in Czech format there's no problem.
Have you already found a problem like this?

Thank you in advance!

mihail_kolev

what is the date format that run the Server?

Troubles_In_Paradise

mihail_kolev wrote:

what is the date format that run the Server?

It's Italian...

mihail_kolev

try to change the date format on server to be the same as the client. The date formats on server and client should be the same.

Troubles_In_Paradise

mihail_kolev wrote:

try to change the date format on server to be the same as the client. The date formats on server and client should be the same.

ok Mihail I try and I'll let you know.
Thanks for suggestion.

Troubles_In_Paradise

mihail_kolev wrote:

try to change the date format on server to be the same as the client. The date formats on server and client should be the same.

Hi Mihail, we changed the Culture on the Nav Server but no change...

manisharma31

Have you checked with standard pages for this issue.

Troubles_In_Paradise

manisharma31 wrote:

Have you checked with standard pages for this issue.

I'm sorry, I didn't find a standard page that make a filter on SubPage with a date field.
Could you suggest me please?

Thank you very much.

mihail_kolev

Troubles In Paradise wrote:

mihail_kolev wrote:

try to change the date format on server to be the same as the client. The date formats on server and client should be the same.

Hi Mihail, we changed the Culture on the Nav Server but no change...

I was talking about the date format strings settings. For example, the bulgarian format always append " г." at the end of the date, sounds quite the same issue. And when the format strings are different this is what happens. Did you ensure that the format strings (in Advanced settings of Regional and Language settings) are the same?

Also check the System Locale setting - Regional and Language->Administrative

Troubles_In_Paradise

Hi Mihail here enclosed some screeshot from server.


Also in tab Administrative there's Slovakia.
The Client Machine has the same settings...
Maybe we're missing somenthing in DB settings?
I really don't know...
thank you very much...

Troubles_In_Paradise

Another update with my latest test.
Switched all settings on my pc in Slovack:
*Formats Tab
*Location Tab
*Keybords
*Language for non unicode programs
So the only other thingh not in Slovack is the Dispaly Language.
I run RTC on my pc pointing to a DB installed on my pc with the RTC service installed on my pc and (so... all on the same machine).
Executing the same test... no luck

Troubles_In_Paradise

Type: Microsoft.Dynamics.Framework.UI.DataBindingException
Message: '10.' is not a valid date.
StackTrace:
     at Microsoft.Dynamics.Nav.Client.DataBinder.NavPageReader.GetPage(PageRequestDefinition pageRequestDefinition, Bookmark pageBookmark)
     at Microsoft.Dynamics.Nav.Client.DataBinder.NavPageReader.GetNext(Int32 noOfBlocks)
     at Microsoft.Dynamics.Nav.Client.DataBinder.NavDataReader.InitialFill(Boolean isMovePrevious)
     at Microsoft.Dynamics.Nav.Client.DataBinder.NavDataReader.FillFirstRowEntryCollection(Bookmark bookmark, Boolean movePrevious)
     at Microsoft.Dynamics.Framework.UI.VirtualRows.FillFirstBlock(Bookmark bookmark, FillDirection fillDirection)
     at Microsoft.Dynamics.Framework.UI.BindingManager.DoFill(Bookmark bookmark, FillDirection fillDirection)
     at Microsoft.Dynamics.Framework.UI.BindingManager.Fill(BindingManagerFillOptions options)
     at Microsoft.Dynamics.Framework.UI.BindingManager.Fill(Bookmark bookmark, Boolean isMovePrevious)
     at Microsoft.Dynamics.Nav.Client.Communication.NavBindingManagerConsumerPort.DoFill(Boolean deferFilling)
Source: Microsoft.Dynamics.Nav.Client.UI
----------------------------------

Hi guys. Today we did some further tests.
With SQL profiler we saw that query is correct and data are sent in the correct way to the NAV Server, in fact no errros in the Middle-tier.
The error I attached is on client machine.
It seems RTC interprets space like "end of field".

mihail_kolev wrote:

I was talking about the date format strings settings. For example, the bulgarian format always append " г." at the end of the date, sounds quite the same issue. And when the format strings are different this is what happens.

The different behaviour could be explained in this way... your format is d.M.yyyy r. the space is between year and r.
Assuming that RTC cuts the field as soon as he reaches a space, to filter it uses d.M.yyyy that anyway it's a correct date.

Troubles_In_Paradise

Troubles In Paradise wrote:

The different behaviour could be explained in this way... your format is d.M.yyyy r. the space is between year and r.
Assuming that RTC cuts the field as soon as he reaches a space, to filter it uses d.M.yyyy that anyway it's a correct date.

See the attachment... system filters using 10.04.12 instead of 10.04.12 r.
RTC cuts dates field as soon as it reaches a space...

mihail_kolev

This is interesting. I'll give it a try when I have enough time. A bit strange issue for sure.

Troubles_In_Paradise

To let users work we "cut" spaces in date format for the moment.
Anyway it's only a workaround...