Hi,
I don’t know much about Progress, I’m a C# developer and all the backend stuff for this app is Progress. We have Progress guys here and, they’ve no idea what could be causing this issue I have.
This app is run in Canada and we’ve written the front-end code to display all date / times in the format of whatever the PC is running. The “what’s the PC want to display” thing works everywhere on the planet (and is probably working here to) but, I’m wondering if anyone has ever heard is this problem.
90% of this app is a header datagrid, double-click a row, display a detail datagrid set-up. At this location I’m having a problem with, the detail datagrids are coming up blank and a search by date returns no results.
The closest I’ve come to reproducing the issue in the office is to set the PC to display a 2 digit year and to treat 2 digit years as 1900s.
Problem with that is they are using 4 digit years.
We checked the startup.pf file and it’s configured the same way as our test servers (we can’t dial in and check on their stuff, its a serious pain).
So, has anyone ever hear of a server reformatting a set date / time format in between front-end and back-end? Is that even possible?
I don’t want to go to Canada.
Thank you.
J
Four thoughts:
1) What is the -d parameter at each site?
2) What is the -yy parameter at each site?
3) You are aware that in the code, dates are always dmy, regardless of the display setting?
4) If your issue is differences between client and server, then what about parameter setting differences between the two?
Note that if there is no -d or -yy parameter being set at process startup, these might be set in startup.pf in $DLC as install defaults.
Besides, it can be fun to visit Canada ... depending on what part and the time of year!
Hi,
Thank you for your response... I'll double check these in the morning.
It's just driving me nuts that this is the only location that's having a problem... the same code works all over the world
I hope Vancouver is nice this time of year.
Vancouver is a pretty good place to visit regardless of time of year. Good luck on not solving your problem so that you get to go there!
While this sounds very much like an issue with -d and -yy settings as Thomas suggested, I'd like to know f you are actually talking about a Progress client or a C# client using OpenClient Toolkit or ODBC access?
Next question: Are date values (filter values) passed between client and server in strings or in Data/DateTime variables? If the latter is the case, I doubt that the -d and -yy settings cause these issues. Progress takes care of the proper conversion of date values.
If they are passed as strings, they are.
If you are running a Progress client and for what ever reason date values need to be passed in string variables, you should consider setting them to a known format (-d and -yy parameter) whenever you do conversions from data to string and back. That can be done using the SESSION system handle and the DATE-FORMAT and YEAR-OFFSET attributes. They change the value of -d and -yy at runtime.
So you could use a fixed value (let's say mdy and 1950) for passing values to the appserver and each user could receive the display format of the region he lives in.
I'd go for 4 digit years everywhere. Who knows, what 08 should stand for? 1908 or 2008?
You said, that you don't receive an error, but that grids stay empty. If you are using an appserver at the backend, please ask the 4GL developers to add some debugging code or the QryInfo logfile option to get information about the actual ran queries. That you'll see if date values in query strings are message up.