Problem with dbexpoda40.dll version 4.20.8!

PontusAtNilex · Post by **PontusAtNilex** » Fri 28 Mar 2008 11:20

Hello!

When running our application with dbexpoda40.dll with version 4.20.8
we get the following error :

A dump from Eurekalog

EurekaLog 6.0.11

Application:
-------------------------------------------------------
1.1 Start Date : Fri, 28 Mar 2008 12:16:56 +0100
1.2 Name/Description: plus.exe
1.3 Version Number :
1.4 Parameters :
1.5 Compilation Date: Fri, 28 Mar 2008 11:07:11 +0100
1.6 Up Time : 12 seconds

Exception:
---------------------------------------------------------------------------------------------------------
2.1 Date : Fri, 28 Mar 2008 12:17:09 +0100
2.2 Address : 005A16D1
2.3 Module Name : plus.exe
2.4 Module Version:
2.5 Type : TDBXError
2.6 Message : Unknown param data type (115) (D:\Projects\Delphi\Dbx\Source\dbexp.pas, line 2722).
2.7 ID : E6A3
2.8 Count : 1
2.9 Status : New
2.10 Note :

--------

THis does not happen with version 4.20.6 of dbexpoda40.dll.

the path
(D:\Projects\Delphi\Dbx\Source\dbexp.pas, line 2722) is strange, nothing i can relate to.

Best Regards

Pontus Ihr
Nilex AB

Plash · Post by **Plash** » Fri 28 Mar 2008 11:38

Please specify the steps to reproduce this problem, or send to dbxoda*crlab*com a complete small sample that demonstrates the problem, including the script for creating database objects.

PontusAtNilex · Post by **PontusAtNilex** » Fri 28 Mar 2008 14:02

Hello!

It is not so simple to create a example, but i have pinned down the error in our source, and it occurs when executing a stored procedure in oracle 10 database.

The Code snippet is like this :

OracleGetSerial.ParamByName('tabellid').AsString := cds.info.get('keys');
OracleGetSerial.ParamByName('TabellNamn_I').AsString := cds.info.get('table');
OracleGetSerial.ParamByName('antal').AsFloat := antal;
OracleGetSerial.ExecProc; <<<------ ACCESS VIOLATION!!!!!!

Result := OracleGetSerial.ParamByName('Result_W').AsInteger;

I have verified that the inparameters are correct and that the datatypes are the same.

just by switching dll the access violation occurs.

I will see if i can prepare an example, hope my information is enough to find the problem

Best Regards

Pontus Ihr
Nilex AB

Plash · Post by **Plash** » Mon 31 Mar 2008 07:58

It is possible that the problem is caused by using AsFloat property for ANTAL parameter. Please check the data type of the parameter. If it is ftBCD or ftFMTBcd, you should use Value property to assign parameter's value, because using AsFloat property changes parameter type to ftFloat.

PontusAtNilex · Post by **PontusAtNilex** » Wed 09 Apr 2008 10:24

Hello!

I have made a test changing from .AsFloat to .Value but with the same result as above.

Dont know what to do now..

Best Regards,

//Pontus

Plash · Post by **Plash** » Thu 10 Apr 2008 07:07

We could not reproduce the problem. Please send to dbxoda*crlab*com a complete small sample that demonstrates the problem, including the script for creating database objects.

MattiasNilssonAtNilex · Post by **MattiasNilssonAtNilex** » Wed 06 Aug 2008 12:37

Hello,
I'm taking over some of Pontus' work since he moved on to another company.

I tried 4.20.10 (we never tried a 4.20.9), and the good news is that dbexpoda40.dll doesn't blow up anymore.

However, a new problem is introduced with dbexpoda.dll.
Our stored procedure is now returning the ID value 0, instead of a proper ID value. Switching back to the older dll solves the problem.

Here is the code for the procedure, called as above, in Pontus' post:

Code: Select all

CREATE PROCEDURE GETSERIAL(tabellid IN varchar2, 
TabellNamn_I IN varchar2,
antal IN integer,
Result_W out integer) IS 
CurrentId_W LOCKS.IDENT%TYPE;
tmp_number integer;
/******************************************************************************
   NAME:       getserial
   PURPOSE:    Get New id numbers for inserting new records.
******************************************************************************/
BEGIN
  begin
    select LOCKS.IDENT
      into CurrentId_W
      from LOCKS          
     where LOCKS.KIND   = 'SERIAL' 
       and LOCKS.TABLE_ = TabellNamn_I FOR UPDATE;
  exception
      when NO_DATA_FOUND then
        CurrentId_W := null;
  end;
	 	   		   	   
  if CurrentId_W is not null then
  	   tmp_number := to_number(CurrentId_W);
	   tmp_number := tmp_number + antal;
       Result_W := to_number(CurrentId_W) + 1; /* First id*/	   
	   CurrentId_W := to_char(tmp_number);
   	   update LOCKS
       set LOCKS.IDENT  = CurrentId_W
       where LOCKS.KIND   = 'SERIAL' 
       and LOCKS.TABLE_ = TabellNamn_I;	  
  ELSE
       Execute Immediate 'SELECT COUNT(*) FROM ' || TabellNamn_I into Result_W;  
       IF Result_W > 0 THEN
            Execute Immediate 'SELECT MAX(' || tabellid ||') FROM ' || TabellNamn_I into Result_W;  
       END IF;
       tmp_number := Result_W + antal;
	   CurrentId_W := to_char(tmp_number);
       INSERT INTO LOCKS(KIND,TABLE_,IDENT)
       VALUES('SERIAL',TabellNamn_I, CurrentId_W);	   
	   Result_W := Result_W + 1;  	   
   END IF;
END getserial;

Plash · Post by **Plash** » Thu 07 Aug 2008 07:16

This is a known problem. We are planning to release the new build of DbxOda with the fix during this week.

MattiasNilssonAtNilex · Post by **MattiasNilssonAtNilex** » Fri 08 Aug 2008 08:08

Thanks for the quick reply.

I have tested the new 4.20.11 versions (oda, oda40), and this particular problem is solved.

Case closed.

/Mattias