SAP .Net Connector 2.0.1 and .Net Framework 2.0

[Former Member]

Hello,

we have a problem regarding the .Net Connector while using .Net framework 2.0 and hope someone has a solution or workaround.

While calling the function module RFC_READ_TABLE the SAP Connector returns the values of the table "Fields" within the wrong property. The problem appears occasional (about every fifth execution) With .Net framework 1.1 everything works fine. Furthermore we are using VS 2003, the proxies are created in C# and the program is in VB.Net.

Here is an example while dumping the class:

<b>Correct:</b>

FieldListName: Fieldname Wert: SANFE

FieldListName: Offset Wert: 000000

FieldListName: Length Wert: 000001

FieldListName: Type Wert: C

FieldListName: Fieldtext Wert: Kennzeichen: Fertigungsrelevanz Position

<b>false:</b>

FieldListName: Fieldname Wert: 000000

FieldListName: Offset Wert: 000001

FieldListName: Length Wert: C

Has anyone an idea? In the forum I read that the SAP Connector works with .Net Framework 2.0

Thanks a lot for your help,

Patrick Oppel

[Former Member · Accepted solution]

Hi Patrick,

how are you doing ?

please allow me to understand a few things :-

you have generated proxies with NCo 1.1

they work fine when u use .NET 1.1

when you move to NCo 2.0.1 and .NET 2.0

the behaviour is unpredictable

-

---

a few checks :-

1> the proxies are regenerated for NCo 2.0.1 on .NET 2.0

2> the data is the only variable which could cause unpredictability in this case as the structure should remain constant, please provide a successful and unsuccessful data difference mapping

for RFC_READ_TABLE, when testing, please keep the volume of data low, and within the parameters ( check for lengths of fields) as it is not the most robust of RFC's and SAP recommends phasig out of the RFC

however it is still usable when you are aware of the limitations and can work around them

the main input then becomes the table name, and if it has fields which are over the length that the rfc can accommodate, then it usually crashes, so pick your fields carefully or put a max length checker on fields that are over the limit

with respect,

amit

[Former Member · Accepted solution]

Hi Amit,

thanks a lot for your response. In the meantime we did some more testing for bordering the error.

The proxies have been created with NCo 2.0.1 and .Net 2.0. The interface works fine with .Net 1.1 (The proxies we created once with VB and once with C#)

It seems that the NCo returns the data in the wrong class properties if we fill a Table (IN/OUT-Parameter) before calling the function module.

Here is the example for the function module RFC_READ_TABLE:

1. Fill QUERY_TABLE with T416V

2. Fill Fieldname in fields with SANFE; SANKO, SANKA, SANVS, SANIN, ERSKZ, RVREL

3. Fill Options with STLAN = '1'

4. Execute the function

5. Analyze the Class RFC_DB_FLD for the table Fields -> sometimes the description is in the field offset and the other time maybe in the field Fieldname,....)

But the wrong behavior in Step 5 is irregular. Sometimes its correct and then its on error. We are querying the identical data within this call.

If we don't fill the fields parameter the error doesn't appear. For this function we could deal with that, but the same error occurs in the structure T_STOP of the function module CSAP_MAT_BOM_MAINTAIN.

Something else I recognized is that these two structures have fields with the data type NUMC But in fact I don't know if it is a reflection problem in .Net, the NCo has a bug or Unicode leads to the problem.

Thanks for your help.

Kind regards,

Patrick

[Former Member · Accepted solution]

Hi Patrick,

how are you doing today ?

yes when unicode chars are used in the input and output structures, the offsets will definitely change for systems]

proxies for unicode and non unicde system need to be differentiated and will cause the system to be unpredictable

another issue worht looking at is the actual data when it fails, it is this that will cause the unpredictability as this will cause the structure offsets to be ambigious

with respect,

amit