on 09-15-2014 9:46 AM
Hi All,
I am trying to find an appropriate .NET type best matching DECF16 (eight-byte decimal floating point number, ABAP type a) and DECF34 (sixteen-byte decimal floating point number, ABAP type e) ABAP types. I thought, System.Decimal would be a good candidate for this role. However, when I try to use it for setting a value of a field of type DECF16 in a structure, the following exception is thrown:
...
SAP.Middleware.Connector.RfcTypeConversionException: FIELD F_DF16_DEC of STRUCTURE ZSPF_UT_S_001 (SETTER): cannot convert Decimal into DECF16 ---> SAP.Middleware.Connector.RfcTypeConversionException: Cannot convert decimal -20910087939212300000000000000 into DECF16 ---> SAP.Middleware.Connector.RfcTypeConversionException: Cannot convert string "-20910087939212300000000000000" into DECF16 ---> SAP.Middleware.Connector.RfcTypeConversionException: decfloat shared library could not be loaded
at SAP.Middleware.Connector.RfcDecFloat.InitRfcDecFloat()
at SAP.Middleware.Connector.RfcDecFloat.StringToDecFloat16(String value)
at SAP.Middleware.Connector.RfcScalarMetadataDecF16.ConvertString(String value, ref Object currentValue)
--- End of inner exception stack trace ---
at SAP.Middleware.Connector.RfcScalarMetadataDecF16.ConvertString(String value, ref Object currentValue)
at SAP.Middleware.Connector.RfcScalarMetadataDecF16.ConvertDecimal(Decimal value, ref Object currentValue)
--- End of inner exception stack trace ---
at SAP.Middleware.Connector.RfcScalarMetadataDecF16.ConvertDecimal(Decimal value, ref Object currentValue)
at SAP.Middleware.Connector.RfcScalarMetadata.ConvertObject(Object value, ref Object currentValue)
at SAP.Middleware.Connector.RfcDataContainer`1.SetValue(Int32 index, Object value)
--- End of inner exception stack trace ---
at SAP.Middleware.Connector.RfcDataContainer`1.SetValue(Int32 index, Object value)
at SAP.Middleware.Connector.RfcDataContainer`1.SetValue(String name, Object value)
...
Am I missing any dependency? Does anybody know how to solve the problem?
Hi,
perhaps you obtain the libicudecnumber.dll from the NW RFC SDK
Contents of the NW RFC SDK - Components of SAP Communication Technology - SAP Library
There is a reference in the sapnco_utils.dll to the above library.
Hynek
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Hynek,
correct. Actually, libicudecnumber shared library is part of the delivery of NCo 3.0. @Michail: Simply copy the library to a place, from which your application can load it. Then it will work.
Best regards,
Markus
Hi Marius and Hynek,
Thanks for quick response!
I have the libicudecnumber.dll file in the same folder where sapnco.dll, sapnco_utils.dll and rscp4n.dll are located. However, the assembly loading sapnco.dll and sapnco_utils is NOT in that folder. I guess that is the reason why the libicudecnumber.dll could not be loaded. It was simply not found. It looks like the library is searched only in the executing assembly folder. In my opinion, it would be more correct to search in the calling assembly folder.
P.S. Here is an exerpt from the SAP .NET Connector 3.0 Programming Guide:
The other two libraries “libicudecnumber.dll” and “rscp4n.dll” do not need to be added as an assembly reference, because they are plain unmanaged C libraries. In most cases they are not required. Only if you use the ABAP type DECFLOAT, your project will need the libicudecnumber.dll, and only if you use the “UseSAPCodepages” parameter, your project will need the rscp4n.dll. In that case make sure they can be found in the PATH environment variable.
Hi Michail
Try to change the searchorder for unmanaged dll's.
[DllImport("kernel32.dll", SetLastError = true)]
private static extern bool SetDllDirectory(string lpPathName);
Using this BEFORE creating any instances from SAPNCO might help.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx
Kind Regards
Beat
Hi, Michail,
for your P.S. comment ...
It's the default behavior of loading an un-managed library...
Hi Petrak
Michail uses SAPNCO inside of AnyCPU - Applications... and because this is not supported by SAP .. he resolves the x86/x64 dll's with the Assembly-Resolve-Event (which Points to x86/x64)... this is the reason why the managed dlls are found... and the unmanaged are not.
(the managed-dlls are referenced in the .Net - App... but they are not directly in the ExecutionPath... so .Net can't find them... and hits the Assembly-Resolve)
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
6 | |
6 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.