I am currently trying to evaluate your program for our company. So far it looks like something we would like to use, but I have run into a problem:
I cannot create new client entries, because the validation for the billing/tax rate fields does not seem to accept the German decimal separator ','. At least I think that this is the problem, as I get the error "Billing rate must be numeric" when I try to create a new client ...
I have installed the TimeEntry package on a German Windows 2003 Server machine. I am using Java SDK 1.6. I guess Java is using the locale of the OS, as floating point numbers like the billing and tax rates are shown in (and auto-corrected to) German floating point notation ("0,345" instead of "0.345"). I am not a Java/TomCat/jRivet expert, so I have no idea how to tackle this problem.
Thanks for any help in advance,
Oliver
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a problem we hope to correct in our next release. The locale Web Time Entry is using is somewhat hard coded to western in our current release. The current release must use a '.' as the decimal separator.
So... Stay tuned - you are not the first to ask for this fix. It is near the top of things to do (along with adding multi-language support).
Hope this helps,
Paul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, that explains.
Although it does not really help ... :)
This pretty much rules out your software. Multi-language support wouldn't be a must-have, everybody working on a computer in Germany should be able to use an interface in English. But changing the server's locale (and possibly the client's too?) would most certainly create more problems than it is worth.
So, any chances to get rid of the problem with some hot fix? Like overriding some central validation method for floating point numbers and loading the decimal separator from the current locale? I would still be glad to be able to use your software.
Oliver
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got the problems on Windows XP french version:
- any date entered event through the "time picker" is changed by WebEntry (example: project management: Start & End Date)
- any floating numbers entered generate an invalide data error.
Web Time Entry looks really greate but it's a pity we cannot even test it ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The date format can be set in –-> Start Administrative Tasks –-> Edit Users Groups. Each user group can have a different date format and the applet will ‘flip’ entered dates around to that format. This is by design to ensure all dates stay within one given format for a user group (regardless of how the user enters a date). Currently we don’t support ddmmyy simply because the applet has no possible way know what six digit date represents unless we force them to enter always in one format. This is an option we try to stay away from. Change the format to ddmmyyyy or yymmdd or yyyymmdd and have your users enter the date as such.
Floating point numbers in 9.999,00 format should be supported in our current release (but this is untested) - Any feedback would be great!
And point 3 you missed... "We could also use French translations of our screen XML" – so if your know anyone….!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried the suggested formats, but the problem remains the same.
I'm testing the project maintenance screen.
XP Professional SP2
Web Entry - jRivet Framework - version V4.070310 2007/03/10
JDK 1.5.0
Access (Office 2002) through ODBC
Date format
-----------
1. the system doesn't understand the month in "mm" format but "MM". this can be checked on the welcome screen showing dates, username ...
2. with the ddMMyyyy format (standard in french speeking countries) , the system would interpret 01072007 (1st Jul. 2007) as 7th Jan. 2007. Even if you don't directly type in the date but select it in the "datepicker" dialog box.
3. The default format "dd MMM yyyy" is the worst, every time you click in a date field its value changes.
4. "MM dd yyyy" is the only date format understood by the system.
Hour format
-----------
1. the display format of "budgeted hours" is like "99 99". Why ?
2. As a consequency, if you view the detail of a project without changing any thing and click on "add/update", you get the message "Budgeted Hours must be numeric"
3. If you modify the "budgeted hours", you get the above message when living the field. The only way to "add/update" a project is to stay in the "budgeted hours" field and click on "Add/Save". Unfortunatly the project will be saved, not the changes to the "budgeted hours" field.
I suspect our database or software has the wrong configuration.
French localization
-------------------
We are ready to do it as soon as our tests are sucessfull ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We support ALL (yes ALL) date formatting based in Sun’s 1.6 SimpleDateFormat API with the exception of "ddmmyy" as outlined above. You can review the format edit codes at http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html. “mm dd yyyy” IS NOT the only date format usable on the system. Again – To set the date format goto - Start Administrative Tasks –-> Edit Users Groups. Each user group can have a different date format and the applet will ‘flip’ entered dates around to that format (again - this is to ensure one format is used within a user group). Many, many other users are using other date formats other then "mm dd yyyy". Just ask around.
Not sure what the issue is with "budgeted hours". It is a numeric floating-point value that is displayed and edited as 999.99 or 999,99 (based on your default locale). I suspect you have an issue with the locale on your server or even within MS Access. This would also explain all problems you are having with date formatting (that other users seem NOT to have). I am sure you are also having the same issue on all other numeric fields within Web Time Entry.
I would install it to another database (MySQL or Derby) and even another machine. Then start your testing again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But I steal have the floatting numbers problem issued by Oliver Kastrup!
With the exception that the '.' doesn't fix the problem ie :
- if I entered 12.5 I get "Budgeted hours must be numeric" error message
- but if I 'add/update', I got the ugly message!
I've changed the decimal seperator from "," (the default) to "." in "regional settings" in Windows Control Panel. Unfortunatly it doesn't help.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Youpi back at ya! sounds like you are making progress!
This is still a locale problem. Mr Kastrup problem was in an old release and has been corrected (but we have done very limited tested as multi-locale support is not big when it comes to feature requests - sorry but its just a fact). Does this happen on all floating-point numbers? What format is the client trying to put them in (still in your "999 99" format - cause that is not correct at all)? What browser are you running and what version of Java is it running. Is the locale set different on the server? What version of Java is on the server?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are also sure it's a locale problem ... but we really have no idea on where to entered the right configuration.
Here the answers to your questions:
- Yes we have this problem on all floating-point numbers
- the display format of floating-point number is "999 99", ie in the project maintenance form the default value for "budgeted hours" is "0 00". Any number entered in a floating-point number field without "," or "." is converted to this display format ... Examples:
* "12" entered will be "0 12"
* "120" entered will be "1 20"
- We are using
* Microsoft Internet Explorer 7.0
* java JDK 1.5.0
- Regarding the locale, we are testing everything on a stand alone PC ie client and server are on the same machine.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Based on the fact the you are getting a blank character as the decimal separator I would say that the locales are crossed between your browser, Tomcat and/or MySQL. And blank decimal separate in ANY system locale is an invalid floating-point number, so we can say Web Time Entry is validating the value as it should - as an invalid value.
An example of your problem would be; your client browser wants for format floating points as 999,99 Tomcat wants to do it as 999.99 and MySQL want to use one of the two (or some other mixed up combination like that). This would, for sure end-up displaying the decimal separator as a blank on all floating-point fields. I think if you get all the locales on the same page – your problem will go away.. And just because they are running all on the same computer does NOT mean they are running with the same locales. Your best bet is to review any and all Tomcat, MySQL and Jave docs on setting locales. Then ensure you have all set correctly.
Here are a few links on how to set locales in Tomcat and MySQL.
I'm back ... unfortunately with questions.
Looks like our problem comes from a missing locale file in Tomcat.
We've tryed but couldn't find the format orany sample of these files ("/MyApps/index.html" or "/MyApps/index_xxxxx.html"). Can you help ?
Thanks,
Nafanga.
PS: we've reinstall Tomcat carefully to be sure to not miss any question related to the topic ... no locale files ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have reinstall everything carefully, no doubt on that!
We have checked
- MySQL language parameter: fr_FR (great for us)
- the web server MSIE : also fine
- jakarta-tomcat : there is an index.html file found in C:\WebTimeEntry\jakarta-tomcat-5.5.7\webapps\ROOT. We think something is missing there like en_US or fr_FR but we don't know what and how!
Now when we change the regional settings in windows control panel to "english US" everything works perfect. When back to "french FRANCE": problem with numbers!
I would then say that we are 100% in the initial floating number problem highlighted by Paul Kastrup or we are definitely lost ...
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Paul,
I am currently trying to evaluate your program for our company. So far it looks like something we would like to use, but I have run into a problem:
I cannot create new client entries, because the validation for the billing/tax rate fields does not seem to accept the German decimal separator ','. At least I think that this is the problem, as I get the error "Billing rate must be numeric" when I try to create a new client ...
I have installed the TimeEntry package on a German Windows 2003 Server machine. I am using Java SDK 1.6. I guess Java is using the locale of the OS, as floating point numbers like the billing and tax rates are shown in (and auto-corrected to) German floating point notation ("0,345" instead of "0.345"). I am not a Java/TomCat/jRivet expert, so I have no idea how to tackle this problem.
Thanks for any help in advance,
Oliver
Hi..
This is a problem we hope to correct in our next release. The locale Web Time Entry is using is somewhat hard coded to western in our current release. The current release must use a '.' as the decimal separator.
So... Stay tuned - you are not the first to ask for this fix. It is near the top of things to do (along with adding multi-language support).
Hope this helps,
Paul
Ah, that explains.
Although it does not really help ... :)
This pretty much rules out your software. Multi-language support wouldn't be a must-have, everybody working on a computer in Germany should be able to use an interface in English. But changing the server's locale (and possibly the client's too?) would most certainly create more problems than it is worth.
So, any chances to get rid of the problem with some hot fix? Like overriding some central validation method for floating point numbers and loading the decimal separator from the current locale? I would still be glad to be able to use your software.
Oliver
Again, Stay tuned - you are not the first to ask for this fix. It is near the top of things to do
Paul
Any progress on this subject ?
I got the problems on Windows XP french version:
- any date entered event through the "time picker" is changed by WebEntry (example: project management: Start & End Date)
- any floating numbers entered generate an invalide data error.
Web Time Entry looks really greate but it's a pity we cannot even test it ...
The date format can be set in –-> Start Administrative Tasks –-> Edit Users Groups. Each user group can have a different date format and the applet will ‘flip’ entered dates around to that format. This is by design to ensure all dates stay within one given format for a user group (regardless of how the user enters a date). Currently we don’t support ddmmyy simply because the applet has no possible way know what six digit date represents unless we force them to enter always in one format. This is an option we try to stay away from. Change the format to ddmmyyyy or yymmdd or yyyymmdd and have your users enter the date as such.
Floating point numbers in 9.999,00 format should be supported in our current release (but this is untested) - Any feedback would be great!
And point 3 you missed... "We could also use French translations of our screen XML" – so if your know anyone….!
I've tried the suggested formats, but the problem remains the same.
I'm testing the project maintenance screen.
XP Professional SP2
Web Entry - jRivet Framework - version V4.070310 2007/03/10
JDK 1.5.0
Access (Office 2002) through ODBC
Date format
-----------
1. the system doesn't understand the month in "mm" format but "MM". this can be checked on the welcome screen showing dates, username ...
2. with the ddMMyyyy format (standard in french speeking countries) , the system would interpret 01072007 (1st Jul. 2007) as 7th Jan. 2007. Even if you don't directly type in the date but select it in the "datepicker" dialog box.
3. The default format "dd MMM yyyy" is the worst, every time you click in a date field its value changes.
4. "MM dd yyyy" is the only date format understood by the system.
Hour format
-----------
1. the display format of "budgeted hours" is like "99 99". Why ?
2. As a consequency, if you view the detail of a project without changing any thing and click on "add/update", you get the message "Budgeted Hours must be numeric"
3. If you modify the "budgeted hours", you get the above message when living the field. The only way to "add/update" a project is to stay in the "budgeted hours" field and click on "Add/Save". Unfortunatly the project will be saved, not the changes to the "budgeted hours" field.
I suspect our database or software has the wrong configuration.
French localization
-------------------
We are ready to do it as soon as our tests are sucessfull ;)
just a quick update: the our successfull date format is ddMMyyyy not "dd MM yyyy"
Thanks
We support ALL (yes ALL) date formatting based in Sun’s 1.6 SimpleDateFormat API with the exception of "ddmmyy" as outlined above. You can review the format edit codes at http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html. “mm dd yyyy” IS NOT the only date format usable on the system. Again – To set the date format goto - Start Administrative Tasks –-> Edit Users Groups. Each user group can have a different date format and the applet will ‘flip’ entered dates around to that format (again - this is to ensure one format is used within a user group). Many, many other users are using other date formats other then "mm dd yyyy". Just ask around.
Not sure what the issue is with "budgeted hours". It is a numeric floating-point value that is displayed and edited as 999.99 or 999,99 (based on your default locale). I suspect you have an issue with the locale on your server or even within MS Access. This would also explain all problems you are having with date formatting (that other users seem NOT to have). I am sure you are also having the same issue on all other numeric fields within Web Time Entry.
I would install it to another database (MySQL or Derby) and even another machine. Then start your testing again.
With MySQL no date problem any more ... Youpi!
But I steal have the floatting numbers problem issued by Oliver Kastrup!
With the exception that the '.' doesn't fix the problem ie :
- if I entered 12.5 I get "Budgeted hours must be numeric" error message
- but if I 'add/update', I got the ugly message!
I've changed the decimal seperator from "," (the default) to "." in "regional settings" in Windows Control Panel. Unfortunatly it doesn't help.
Thanks
Youpi back at ya! sounds like you are making progress!
This is still a locale problem. Mr Kastrup problem was in an old release and has been corrected (but we have done very limited tested as multi-locale support is not big when it comes to feature requests - sorry but its just a fact). Does this happen on all floating-point numbers? What format is the client trying to put them in (still in your "999 99" format - cause that is not correct at all)? What browser are you running and what version of Java is it running. Is the locale set different on the server? What version of Java is on the server?
Hi Paul
We are also sure it's a locale problem ... but we really have no idea on where to entered the right configuration.
Here the answers to your questions:
- Yes we have this problem on all floating-point numbers
- the display format of floating-point number is "999 99", ie in the project maintenance form the default value for "budgeted hours" is "0 00". Any number entered in a floating-point number field without "," or "." is converted to this display format ... Examples:
* "12" entered will be "0 12"
* "120" entered will be "1 20"
- We are using
* Microsoft Internet Explorer 7.0
* java JDK 1.5.0
- Regarding the locale, we are testing everything on a stand alone PC ie client and server are on the same machine.
Thanks
Based on the fact the you are getting a blank character as the decimal separator I would say that the locales are crossed between your browser, Tomcat and/or MySQL. And blank decimal separate in ANY system locale is an invalid floating-point number, so we can say Web Time Entry is validating the value as it should - as an invalid value.
An example of your problem would be; your client browser wants for format floating points as 999,99 Tomcat wants to do it as 999.99 and MySQL want to use one of the two (or some other mixed up combination like that). This would, for sure end-up displaying the decimal separator as a blank on all floating-point fields. I think if you get all the locales on the same page – your problem will go away.. And just because they are running all on the same computer does NOT mean they are running with the same locales. Your best bet is to review any and all Tomcat, MySQL and Jave docs on setting locales. Then ensure you have all set correctly.
Here are a few links on how to set locales in Tomcat and MySQL.
http://www.jajakarta.org/tomcat/tomcat3.2-4.0/tomcat-3.2.3/doc/tomcat-localization-howto.html
http://dev.mysql.com/doc/refman/5.0/en/locale-support.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4341292
Good luck and let us know how you make out.....
Hi,
I'm back ... unfortunately with questions.
Looks like our problem comes from a missing locale file in Tomcat.
We've tryed but couldn't find the format orany sample of these files ("/MyApps/index.html" or "/MyApps/index_xxxxx.html"). Can you help ?
Thanks,
Nafanga.
PS: we've reinstall Tomcat carefully to be sure to not miss any question related to the topic ... no locale files ...
I'm back now with better news.
We have reinstall everything carefully, no doubt on that!
We have checked
- MySQL language parameter: fr_FR (great for us)
- the web server MSIE : also fine
- jakarta-tomcat : there is an index.html file found in C:\WebTimeEntry\jakarta-tomcat-5.5.7\webapps\ROOT. We think something is missing there like en_US or fr_FR but we don't know what and how!
Now when we change the regional settings in windows control panel to "english US" everything works perfect. When back to "french FRANCE": problem with numbers!
I would then say that we are 100% in the initial floating number problem highlighted by Paul Kastrup or we are definitely lost ...
Thanks.
sounds like you are up and running (I think) .... So really all the issues you had are with Tomcat and MySql...
Yes we are back to ya again !!!
The problems were with Tomcat and MySQL.
After carefully reinstalling them and checking all the settings, everything is up and running now!
Thanks for all your help!
Nafanga.