But NOT with TD5.2 SP2.
I isolate the problem.
Call SqlConnect ( hSql )
Set sFilial = "001"
Set nQtdPedidos = 1
Set asPedidos  = "00004470"
Set sPLSQLCommand = "PCK_PIR_PEDIDO_VENDA.MudaStatusPedidos( sFilial, nQtdPedidos, asPedidos, dtCancel, nCodErro)"
Call SqlPLSQLCommand( hSql, sPLSQLCommand)
error no: 1618
msg: Invalid parameter type for procedure/external function
The problem is that in TD5.2 SP1 EMP 5259 anothers packages call stops with a sql error that does not occurs with TD5.2 SP2.
So I have some of code that going to error in TD5.2 SP1 EMP 5259 and another part of our application that stops in an error with TD5.2 SP2.
Unify already knows this error ?
How can I help you to reproduce this error ?
the way it is now our client does not approve our system.
I need to have two computers with different deployment files to our application would place orders on a computer and finish the sale in another computer.
this situation is very dangerous to us.
As Kim already answered, we have also encountered this problem and seen that it is the datatype and order of PL/SQL input parameters which causes the SQL error.lairton wrote:The following instruction run correctly in all CTD1.5.1 and TD5.2 SP1 EMP 5259.
But NOT with TD5.2 SP2.
I guess in your PL/SQL call
Code: Select all
PCK_PIR_PEDIDO_VENDA.MudaStatusPedidos( sFilial, nQtdPedidos, asPedidos, dtCancel, nCodErro)
and "dtCancel" is a date. Did I guess right?
As a workaround, try to change the order of parameters. E.g. move the number array to the first parameter, or the last. For us this has helped.
For us too, so we are waiting a quick fix from Unify. They are aware of this issue and currently investigating it. Hopefully more information is received within the next few days.lairton wrote:this situation is very dangerous to us.
That's right! The problem is solved by making the change positions of the parameters.
Is very important that we give a quick answer from Unify (maybe an EMP) about it, because we can not change these parameters in all the packages that we use parameters with date and using arrays. We have about 400 cases of this type of call in our application!
move parameters to another position is a very delicate contour.
what to do when a case like this?
PCK_Abc (arrayNumber1, arrayNumber2, arrayNumber3, arraydate1, arraydate2, arrayDate3)
move to where the arrays?
do not tell me the solution is to do this:
PCK_Abc (arrayNumber1, stringDummy1, arrayNumber2, stringDummy2, arrayNumber3, stringDummy3, arraydate1, stringDummy4, arraydate2, stringDummy5, arrayDate3)
This situation clearly sets a bug in version 5.2.2 sqlora32.dll
I know for sure because if I change just this dll, putting the dll 5.2.1 the application works.
Well, it's not quite that simple. If you put together a small and complete test case -- app, Oracle script, etc. -- I can take a look at it when I get time to get to the forum. And if I can verify if, I'll enter it in as a TD defect.Could someone at Unify respond to this problem and report when a fix will be available?
As for when a 'fix will be available', better click here: https://support.guptatechnologies.com/supportforum/viewtopic.php?f=40&t=3398
to understand what you need to do to request an urgent fix.
Well, whatever the problem is, let's all assume you won't have to do thatwithout having to rewrite the entire application
There should be no need for anyone else to build a test case any more. We have already done it.Jeff Luther wrote:Well, it's not quite that simple. If you put together a small and complete test case -- app, Oracle script, etc. -- I can take a look at it when I get time to get to the forum. And if I can verify if, I'll enter it in as a TD defect.Could someone at Unify respond to this problem and report when a fix will be available?
Problem 00012424 with subject "PL/SQL calls give SQL error 1618" has been logged into your system already on 22nd September. There is detailed information and a test case. Both Jeff and Jean-Marc have replied into this case. The status is still "Researching Solution". The last comment by Jean-Marc says that Mike shall take a look on this... So no TD defect number has been assigned yet.
So far we have been able to live with the workaround, in fact this affected only three of our PL/SQL procedures (altogether hundreds of them). But I definitely agree with all of you, this should really be fixed ASAP.
Who is online
Users browsing this forum: [Ccbot] and 2 guests