Question

Forms submission "Bad field value" 9017 error on Date format after 10.2 upgrade

Forms Version 10

Updated June 11, 2017

asked on February 13, 2017 • Show version history

Hi guys,

We've encountered this issue before with dd/MM/yyyy date formats on Forms and seemed to have resolved it with a restart of the services, but service and full server restarts aren't resolving the issue this time. It's a simple Forms process with a single service task to save the form to the repository. The date field on the form is failing with the error "Bad field value [9017]" when Forms runs the "Save to repository" task and tries to populate the date field in the template.

The process was working previously without any changes other than the upgrade to 10.2, so it's either something to do with the new version, something has been reset during the upgrade process, or a Windows Update has reset something.

I've checked the following:

The date format on the Form Layout is dd/MM/yyyy
The date format in the template is Short Date and if I create a document directly from the template the date "14/02/2017" works fine.
The registry settings on the server/client under "Control Panel \ International" for HU\.DEFAULT and HCU are both set to en-NZ with a short date format of d/MM/yyyy
Firefox, Chrome, and IE 10 are all set to English NZ as the default language but I get the error when using any of the browsers.
I've tested the "Configure Fields" options in the Save to Repository task with both the date field from the form, as well as the Instance initiated date and get the same error.
If I hard code a date in US format (e.g. 02/14/2017 for today's date) it works.
The Forms Router service is running under a local administrator account i.e. a user account and not the "Local System" account.

So somewhere in the process the date is being converted to US format and failing but I can't work out where that's happening.

Any suggestions?

Thanks,

Mike

2 0

Answer

SELECTED ANSWER

replied on February 13, 2017

Hi Mike,

I have confirmed that this is a bug in Forms 10.2. The workaround is to change the locale used by routing service run as account to en-US.

This should be fixed in Forms next update. Sorry for the inconvenience.

0 0

View 1 previous reply

replied on February 13, 2017

Rui,

We have the same issue also with 10.2, affecting writing Dates into a Date field when saving to a repository. We require the format dd/MM/yyyy. All the changes on previous posts in LF answers & The Help guide solutions have not made any difference.

Can you please be more specific? There are so many places to change Date formats. Eg

- Time zones UTC + xxxx

- Customize Date format

- Region formats (English US, UK.......)

- Home Location

- Administrative Copy Settings (shows Display language, Inout Language, Format, Location)

- Change system locale (Current System locale)

???

0 0

replied on February 14, 2017

Hi Rui,

Thanks for the suggested workaround, it enables the form to be saved to the repository successfully, however in testing I have found that if the template date field is populated with "{/dataset/_initiated_date}" in the Save to Repository - Configure Fields mappings, then the date is wrong. e.g. at 9am NZ time on 15 Feb, it is still 14 Feb under the US locale so using the Instance Start Date/initiated_date token to populate the template date field will input the previous day's date. I'm not sure what actual time zone the US Locale setting will set to, but as at 9am in NZ it could be anywhere up to 12 hours (based on current time/date in Los Angeles) before the US locale setting switches to the same date as it is in NZ.

The additional workaround is to have a date field on the form and use that rather than the Instance Start Date token.

Regards,

Mike

0 0

replied on February 14, 2017

Grant, to get it to work I set up an additional Administrator level user account (both in Windows to enable it to run as a service, and in Laserfiche), logged in with the account and set the user's "Region and Language - Format" to "English (United States)". I then changed the Laserfiche Forms Routing Service Log On account to the new user account, restarted the service, and was able to get forms to save to the repository again. All other user and system accounts are still set to our default "English (New Zealand)" locale.

Cheers,

Mike

0 0

replied on February 14, 2017

Thanks Mike,

We have tried those steps also. I have a case logged with support, still waiting for a fix.

cheers

1 0

Replies

replied on March 9, 2017

Hi,

Forms 10.2 Update 1 has been released and this problem is fixed in this update.

You can get the patch for this at https://support.laserfiche.com/kb/1013834/list-of-changes-for-laserfiche-forms-10-2-update-1-

Thanks.

3 0

replied on March 9, 2017

Thank you!

0 0

replied on February 14, 2017

Hi Mike,

For the "{/dataset/_initiated_date}" issue, the timezone should follow the process timezone, rather than locale/account timezone.

Can you check the process timezone on Process Options page?

0 0

View 4 previous replies

replied on February 15, 2017

Hi Rui,

The timezone is correctly set to "(UTC+12:00) Auckland, Wellington".

Thanks,

Mike

0 0

replied on February 15, 2017 • Show version history

Hi Mike, can you list where you set the timezone to something other than UTC+12? I tried setting all timezone to UTC+12 and the date field in file saved to repository is correct.

For the routing service account, it works as long as the format is in US locale. You could set the timezone of the account to UTC+12 (but it did not affect the date at all during my test).

0 0

replied on February 15, 2017

Hi Rui, it was set in the process timezone on the Process Options page. I've got the service account set to the US locale and with that in place the standard date fields on the form work fine when being mapped to the template, it's just if I used the initiated_date token that the date is wrong.

Thanks,

Mike

0 0

replied on February 15, 2017

Sorry if I didn't explain it clearly, I just meant you could set all timezone (server timezone, or routing service account timezone) to UTC+12.

During my test, I set the date field in STR template with value {/dataset/_initiated_date}, and after the file is saved to repository, the date value follows process timezone. So I'm trying to figure out if there's any other timezone that could affect it.

0 0

replied on February 15, 2017

Hi Rui, all my user and service accounts are set to UTC+12. For clarity, that includes the service account with the US Locale setting that is configured as the log on for the Forms Router Service. I'm unable to find anything in the system with a timezone that isn't UTC+12.

Testing at the moment I'm getting the correct date, but it's currently 15:45pm whereas the issue was occurring in the morning when I was initially testing. I'm away tomorrow but I will test again on Monday morning and let you know the outcome.

Thanks,

Mike

0 0

replied on February 19, 2017

Hi Rui,

I've done some more testing and it is to do with the time of day. Interestingly though, it only looks to be an issue with the "initiated_date" token, "initiated_time" is correct. Here's the test results:

First I updated the Save to Repository task "Configure Fields" options so that the date field on the form files the "Date Requested" field in the template, but replaced the Job Number field data with the initiated date and time tokens:

I then filled out the form with the screenshot showing the date and time on the server - I am testing directly on the Laserfiche dev server ... sorry about the colours! :o)

And here's what the result is in the folder template created in the repository, the date field from the form comes through correctly, initiated_time is correct but in US date format, and initiated_date is both a day out and in US date format. And to confirm, all date settings on the server are in NZ date format, the only US setting is for the Locale for the Forms Router service account, but that account is set to UTC+12:

0 0

replied on February 19, 2017 • Show version history

Hi Mike, thanks for your testing! I was able to reproduce the issue that process date variables, including initiated_date, are not correct in certain cases.

This should be fixed in Forms next update. Sorry for the inconvenience again.

1 0

replied on June 9, 2017

Hi, I'm having an issue very similar to this error. And the customer already has Forms v10.2.0.834 (10.2 Update1) and it's still an issue. Any ideas? Please see attached.

1.PNG (58.67 KB)

| Download

2.png (42.66 KB)

| Download

0 0

replied on June 11, 2017

Hi Peter, can you give more details on the issue?

What is the locale used by routing service run as account? What type of field the "Document Date" field is?

And what is the defined value and runtime value in the "Document Date" field? You can get the runtime value by set the same defined value in a text field.

0 0

You are not allowed to follow up in this post.

Question

Question

Forms submission "Bad field value" 9017 error on Date format after 10.2 upgrade

Answer

Replies

Sign in to reply to this post.