Page 1 of 1

Problem with out parameter / oracle and direct=false.

Posted: Mon 17 Oct 2011 12:22
by andrelau
Hi.
here's the problem.

We mapped a stored procedure and we recently noticed (upgrading to 6.x) that when we call it using 'Direct mode = false', string in the output parameter ends with spaces plus one zero and trim doesn’t work. (creates a bug in our software as we are expecting 11 char after trim.

If we switch to “direct = true” in the config file, it’s ok (string ends with spaces, no ‘zero’ byte’ and trim works.

Details

The setup.
• Oracle windows client 10.2.0.1
• Devart 6.50.228 (same with 6.10) - was working with 5.6+

We call a stored proc inside a package.

Here’s the Oracle Part.

Code: Select all

SUBTYPE st_myparameter IS MyTable.Field%TYPE;
(field is declared as Char(11))

Code: Select all

PROCEDURE MyProcedure(
                                  Arg1    IN     st_myparameter,
                                  Arg2   IN     st_anothersubtype,
                                  arg_o_1       OUT st_myparameter,
                                  arg_o_codret       OUT integer
                                 );
Here’s the .Net part.

In the Model.designer.cs we can find this after the Import.

Code: Select all

public int MyProcedure (global::System.String Arg1, global::System.String Arg2, ObjectParameter arg_o_1, ObjectParameter aRG_O_CODRET)
Q1 : As output subtype should be char(11) is it logical to get a very long string in the arg_o_1 ?
I mean we expect a 11 char string and what we get is 2000 chars long !

Q2: When we use Direct = true the last char of the 2000 is a space. Trim is working fine.
When we use Direct = false , last char is zero and thus, the trim doesn’t work.

Posted: Tue 18 Oct 2011 09:40
by andrelau
up.

Posted: Fri 21 Oct 2011 10:27
by Shalex
We cannot reproduce the problem with dotConnect for Oracle v 6.50.228 basing on the description of the issue above. Please send us a small complete test project with the DDL/DML script of the corresponding database objects.