In the IDE everything is fine, only the EXE has a big problem:
If the Decimal-Separator is set to "." (dot) the value of fondsPrice is "58.57" => OK If the Decimal-Separator is set to "," (comma=> GERMAN decimal separator) the value of fondsPrice is "5857" => BIG problem
The Decimal-Separator comes from here: "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
We did: - Set the Decimal-Separator via RegistrySet() to "." (dot) just before invoking the WebService ip_AssetService.findFondsKurse()
We dont' want: - Convert decimal-Values to String and back - Divide decimal-Values by 100 or something like that
Any ideas to configure DOT.NET? Or PB? Or what ever?
> In the IDE everything is fine, only the EXE has a big problem:
> If the Decimal-Separator is set to "." (dot) the value of fondsPrice > is "58.57" => OK > If the Decimal-Separator is set to "," (comma=> GERMAN decimal > separator) the value of fondsPrice is "5857" => BIG problem
> The Decimal-Separator comes from here: > "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
> We did: > - Set the Decimal-Separator via RegistrySet() to "." (dot) just before > invoking the WebService ip_AssetService.findFondsKurse()
> We dont' want: > - Convert decimal-Values to String and back > - Divide decimal-Values by 100 or something like that
> Any ideas to configure DOT.NET? Or PB? Or what ever?
>> In the IDE everything is fine, only the EXE has a big problem:
>> If the Decimal-Separator is set to "." (dot) the value of fondsPrice >> is "58.57" => OK >> If the Decimal-Separator is set to "," (comma=> GERMAN decimal >> separator) the value of fondsPrice is "5857" => BIG problem
>> The Decimal-Separator comes from here: >> "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
>> We did: >> - Set the Decimal-Separator via RegistrySet() to "." (dot) just before >> invoking the WebService ip_AssetService.findFondsKurse()
>> We dont' want: >> - Convert decimal-Values to String and back >> - Divide decimal-Values by 100 or something like that
>> Any ideas to configure DOT.NET? Or PB? Or what ever?
>>> In the IDE everything is fine, only the EXE has a big problem:
>>> If the Decimal-Separator is set to "." (dot) the value of fondsPrice >>> is "58.57" => OK >>> If the Decimal-Separator is set to "," (comma=> GERMAN decimal >>> separator) the value of fondsPrice is "5857" => BIG problem
>>> The Decimal-Separator comes from here: >>> "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
>>> We did: >>> - Set the Decimal-Separator via RegistrySet() to "." (dot) just before >>> invoking the WebService ip_AssetService.findFondsKurse()
>>> We dont' want: >>> - Convert decimal-Values to String and back >>> - Divide decimal-Values by 100 or something like that
>>> Any ideas to configure DOT.NET? Or PB? Or what ever?
>In the IDE everything is fine, only the EXE has a big problem:
>If the Decimal-Separator is set to "." (dot) the value of fondsPrice >is "58.57" => OK >If the Decimal-Separator is set to "," (comma=> GERMAN decimal >separator) the value of fondsPrice is "5857" => BIG problem
>The Decimal-Separator comes from here: >"HKEY_CURRENT_USER\Control Panel\International\sDecimal"
>We did: >- Set the Decimal-Separator via RegistrySet() to "." (dot) just before >invoking the WebService ip_AssetService.findFondsKurse()
>We dont' want: >- Convert decimal-Values to String and back >- Divide decimal-Values by 100 or something like that
>Any ideas to configure DOT.NET? Or PB? Or what ever?
44,55 <-- It,s a german decimal value ... for us 44.55 4455 <-- That's the bug in PB. The seperator is killed. That's no prob for us but for german decimals. 4555 / 100 <-- I tried this workaround to get my seperator back 44,55 ... OK <- Ah, that works! .......... for this ;)
BUT!!!!
44,6 <-- see above 446 <-- The seperator is killed ... doesn't matter where it is 446 / 100 <-- Ah, my workaround 4,46 <-- damn, that's not the value of step 1 4,46 .... FAILED !!!! <-- owned
>>>> In the IDE everything is fine, only the EXE has a big problem:
>>>> If the Decimal-Separator is set to "." (dot) the value of fondsPrice >>>> is "58.57" => OK >>>> If the Decimal-Separator is set to "," (comma=> GERMAN decimal >>>> separator) the value of fondsPrice is "5857" => BIG problem
>>>> The Decimal-Separator comes from here: >>>> "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
>>>> We did: >>>> - Set the Decimal-Separator via RegistrySet() to "." (dot) just before >>>> invoking the WebService ip_AssetService.findFondsKurse()
>>>> We dont' want: >>>> - Convert decimal-Values to String and back >>>> - Divide decimal-Values by 100 or something like that
>>>> Any ideas to configure DOT.NET? Or PB? Or what ever?
>> In the IDE everything is fine, only the EXE has a big problem:
>> If the Decimal-Separator is set to "." (dot) the value of fondsPrice >> is "58.57" => OK >> If the Decimal-Separator is set to "," (comma=> GERMAN decimal >> separator) the value of fondsPrice is "5857" => BIG problem
>> The Decimal-Separator comes from here: >> "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
>> We did: >> - Set the Decimal-Separator via RegistrySet() to "." (dot) just before >> invoking the WebService ip_AssetService.findFondsKurse()
>> We dont' want: >> - Convert decimal-Values to String and back >> - Divide decimal-Values by 100 or something like that
>> Any ideas to configure DOT.NET? Or PB? Or what ever?
> 44,6 <-- see above 446 <-- The seperator is killed ... doesn't matter > where it is > 446 / 100 <-- Ah, my workaround 4,46 <-- damn, that's not the value of > step 1 > 4,46 .... FAILED !!!! <-- owned
44,6 (or 44.6) is not 446 / 100, it's 446 / 10.
Paul Horan[TeamSybase]
"Benjamin Kemner" <l...@my-signature.de> wrote in message
> 44,55 <-- It,s a german decimal value ... for us 44.55 > 4455 <-- That's the bug in PB. > The seperator is killed. > That's no prob for us but for german decimals. > 4555 / 100 <-- I tried this workaround to get my seperator back > 44,55 ... OK <- Ah, that works! .......... for this ;)
> BUT!!!!
> 44,6 <-- see above 446 <-- The seperator is killed ... doesn't matter > where it is > 446 / 100 <-- Ah, my workaround 4,46 <-- damn, that's not the value of > step 1 > 4,46 .... FAILED !!!! <-- owned
> Arnd Schmidt schrieb: >> Sorry. but I can not understand your mathematics.
>> Can you explain?
>> Arnd
>> On 5 Jul 2008 03:08:39 -0700, John Moon <desertf...@marsmail.com> wrote:
>>> and .... DONT't try to divide by 100 ... it doesn't work
>>>>> In the IDE everything is fine, only the EXE has a big problem:
>>>>> If the Decimal-Separator is set to "." (dot) the value of fondsPrice >>>>> is "58.57" => OK >>>>> If the Decimal-Separator is set to "," (comma=> GERMAN decimal >>>>> separator) the value of fondsPrice is "5857" => BIG problem
>>>>> The Decimal-Separator comes from here: >>>>> "HKEY_CURRENT_USER\Control Panel\International\sDecimal"
>>>>> We did: >>>>> - Set the Decimal-Separator via RegistrySet() to "." (dot) just before >>>>> invoking the WebService ip_AssetService.findFondsKurse()
>>>>> We dont' want: >>>>> - Convert decimal-Values to String and back >>>>> - Divide decimal-Values by 100 or something like that
>>>>> Any ideas to configure DOT.NET? Or PB? Or what ever?
> It's a NOT simple, but it WORKS. > (of course ONLY for DOT.NET-WS)
> To-Know: > - You need access to "Visual C# 2008 Express Edition" > - Somewhere under the directory of <PB-Workspace> is a directory > "TmpWebService" > Here you find a temporary C#-File (<WebServiceName>.cs). > PB respectively DOT.NET use this file to generate the WS-DLL. > Each time a new WebService is generated, the old <WebServiceName>.cs- > File is deleted > - You have to edit the temporary C#-File > 1. Add in the header: > namespace WebService > { > using System.Diagnostics; > using System.Web.Services; > using System.ComponentModel; > using System.Web.Services.Protocols; > using System; > using System.Xml.Serialization;
> //ADD START_HEADER > using System.Reflection; > using System.Threading; > using System.IO; > using System.Globalization; > using System.Reflection.Emit; > //ADD ENDE_HEADER > ...
> Important note: > We did not have success to edit the <WebServiceName>.cs-File in the > directory "TmpWebService" . > We need to use "Visual C# 2008 Express Edition" and build the DLL VIA > a Visual-C#-Project!
> Procedure: > 1. Delete all WebService-DLL in the Project > 2. Generate ONE PB-WebService-Proxy from PB > Copy the generated (temporary) C#-File to a save place > Goto 1 until all WebService-DLLs are generated > 3. Edit each C#-File => Add entrys in the the header/Constructor > 4. Open a Visual-C#-Project for each WebService-DLL > => Build Solution > 6. Copy the genenerated WebService-DLL to the PB-WebService-DLL > directory.
> That's all you have to do ;-)
> Maybe someone from Sybase can check this and may be > in PB 11.5 it will be somehow easier to run a german WS-Client.
Paul Horan[TeamSybase] wrote: > I think your arithmetic is still wrong...
sure, but I can't get the RIGHT way
if I get the service 446, there is no way to determine what's the right source.
Paul Horan[TeamSybase] wrote: >> 44,6 <-- see above 446 <-- The seperator is killed ... doesn't matter >> where it is >> 446 / 100 <-- Ah, my workaround 4,46 <-- damn, that's not the value of >> step 1 >> 4,46 .... FAILED !!!! <-- owned
> 44,6 (or 44.6) is not 446 / 100, it's 446 / 10.
Yes, you are right. But how can I know that the source is 44.6 and NOT 4.46.
It's a NOT simple, but it WORKS. (of course ONLY for DOT.NET-WS)
To-Know: - You need access to "Visual C# 2008 Express Edition" - Somewhere under the directory of <PB-Workspace> is a directory "TmpWebService" Here you find a temporary C#-File (<WebServiceName>.cs). PB respectively DOT.NET use this file to generate the WS-DLL. Each time a new WebService is generated, the old <WebServiceName>.cs- File is deleted - You have to edit the temporary C#-File 1. Add in the header: namespace WebService { using System.Diagnostics; using System.Web.Services; using System.ComponentModel; using System.Web.Services.Protocols; using System; using System.Xml.Serialization;
//ADD START_HEADER using System.Reflection; using System.Threading; using System.IO; using System.Globalization; using System.Reflection.Emit; //ADD ENDE_HEADER ...
2. Add in the Constructor: .... public ClientService () { string urlSetting = System.Configuration.ConfigurationManager.AppSettings["EndpointURL"]; if ((urlSetting != null)) { this.Url = urlSetting; } else { this.Url = "http://localhost:8080/easi-ws/services/ ClientService "; } //ADD START_Constructor System.Globalization.CultureInfo culture = System.Globalization.CultureInfo.CreateSpecificCulture("de-DE"); System.Threading.Thread.CurrentThread.CurrentCulture = culture; culture.NumberFormat.NumberDecimalSeparator = "."; culture.NumberFormat.NumberGroupSeparator = ","; //ADD ENDE_Constructor } ... - Build a "Visual C# 2008 Express Edition"-Project for each C#-File respectively WebService
Important note: We did not have success to edit the <WebServiceName>.cs-File in the directory "TmpWebService" . We need to use "Visual C# 2008 Express Edition" and build the DLL via a Visual-C#-Project.
Procedure: 1. Delete all WebService-DLL in the Project 2. Generate ONE PB-WebService-Proxy from PB Copy the generated (temporary) C#-File to a save place Goto 1 until all WebService-DLLs are generated 3. Edit each C#-File => Add entrys in the the header/Constructor 4. Open a Visual-C#-Project for each WebService-DLL => Build Solution 6. Copy the genenerated WebService-DLL to the PB-WebService-DLL directory.
That's all you have to do ;-)
There is also an issue regarding DateTime-Fields. The original PB-WS changed VALUES from YYYY-MM-DD to YYYY-DD-MM. The DLL generated by Visual C# works also in this case.
Maybe someone from Sybase can check this and may be in PB 11.5 it will be somehow easier to run a german WS-Client.
It think Sybase has noticed since half a year or more about this general "culture info" problem. It was also discussed in other threads include sybase folks.
I am glad you found a solution follwing my attempt.
On Wed, 9 Jul 2008 01:08:44 -0700 (PDT), tomtomuse...@gmx.de wrote: >Hi, >a (genius) colleague found a solution.
>It's a NOT simple, but it WORKS. >(of course ONLY for DOT.NET-WS)
>To-Know: >- You need access to "Visual C# 2008 Express Edition" >- Somewhere under the directory of <PB-Workspace> is a directory >"TmpWebService" > Here you find a temporary C#-File (<WebServiceName>.cs). > PB respectively DOT.NET use this file to generate the WS-DLL. > Each time a new WebService is generated, the old <WebServiceName>.cs- >File is deleted >- You have to edit the temporary C#-File > 1. Add in the header: > namespace WebService > { > using System.Diagnostics; > using System.Web.Services; > using System.ComponentModel; > using System.Web.Services.Protocols; > using System; > using System.Xml.Serialization;
> //ADD START_HEADER > using System.Reflection; > using System.Threading; > using System.IO; > using System.Globalization; > using System.Reflection.Emit; > //ADD ENDE_HEADER > ...
>Important note: >We did not have success to edit the <WebServiceName>.cs-File in the >directory "TmpWebService" . >We need to use "Visual C# 2008 Express Edition" and build the DLL via >a Visual-C#-Project.
>Procedure: >1. Delete all WebService-DLL in the Project >2. Generate ONE PB-WebService-Proxy from PB > Copy the generated (temporary) C#-File to a save place >Goto 1 until all WebService-DLLs are generated >3. Edit each C#-File => Add entrys in the the header/Constructor >4. Open a Visual-C#-Project for each WebService-DLL > => Build Solution >6. Copy the genenerated WebService-DLL to the PB-WebService-DLL >directory.
>That's all you have to do ;-)
>There is also an issue regarding DateTime-Fields. >The original PB-WS changed VALUES from YYYY-MM-DD to YYYY-DD-MM. >The DLL generated by Visual C# works also in this case.
>Maybe someone from Sybase can check this and may be >in PB 11.5 it will be somehow easier to run a german WS-Client.
To be honest: My colleague found the solution by himself. But we are VERY BUSY at the moment. So I took some time to find some time to post our way of handle a german PV-WS-Client ;-)
On Wed, 9 Jul 2008 13:18:33 -0700 (PDT), tomtomuse...@gmx.de wrote: >To be honest: My colleague found the solution by himself. >But we are VERY BUSY at the moment. >So I took some time to find some time to post our way of handle a >german PV-WS-Client ;-)