Hi,
I'm fairly new to Progress and OpenEdge, but now I'm working on my first big project. Upgrading an application from Progress 8 to OpenEdge 10.1c.
The problem I'm currently facing is that the old database server uses a comma (,) as decimal seperator, but the new one uses a dot (.)
Is there a way to import the data using a comma instead? Like with the "-d dmy" proutil parameter for dates?
Any help is appreciated.
sincerely,
Steven
in a progress client session you can see the asci code:
message ASC(",") .
44
You have to start your session using
-numdec 44
thanks for the reply, perhaps I wasn't really clear on what I need.
I'm trying to use the proutil bulkload option to import the data, but in the .d files a comma is used, the new databse uses a dot. so after the import all decimals are suddenly multiplied by 100 (since there were 2 decimal numbers)
the file says 9,55
after import in the new DB it says 955
or is this possible in the proutil command to specify this numdec parameter?
Message was edited by:
Steven Post
Edit: Sorry for misunderstanding, I got it right now, thanks to your hint
Message was edited by:
Steven Post
Yes, I understand your problem.
There is not your new database in cause. The installation of OepnEdge is the cause.
When you install Progress, the wizard ask you for numsep/numdec separators.
The installation wizard save this information to the file:
unix: $DLC/startup.pf
win32: %DLC%\startup.pf
These information are use by default on any client procedure-editor.
You have to change, temporay, these, parameters.
-numsep (numeric separator)
-numdec (decimal separator)
I sugest you to take a look to the old v.8 installation startup.pf and change all this parameters
to be the same in your new environement.
Also, the -cpintenal -cpstream are very important, if charset are diff, you can loose some characters.
thanks for the advice, both cpinternal and cpstream are the same in both installations (so are cpcoll and cpbase), so I don't expect problems there.
I already had a similar issue with the dates being in different formats, mdy instead of dmy, or vice versa. But I had no clue on how to fix the numdec.
Thanks for that.
numsec and numdec are, as far as I know, new features introduced in version 9 or 10 (not sure), so those aren't in the old startup.pf file.
Anyhow, I solved it by using the -numdec 44 parameter in conjunction with proutil -C bulkload, thanks to your advice.
Does it make a difference if I use both the numdec and numsec parameters there (as proutil parameters in proenv) or only numdec, given that all decimals are under 1000? or should I use them both anyhow?
You don't happen to have an answer on my other thread?
No seriously, thanks for saving me from a huge headache
may be take a look to this document:
http://www.psdn.com/library/entry!default.jspa?externalID=3241
I did, last week, but unfortunatly I couldn't find anything related to the screen-value there.