Search found 30 matches
- Sat 19 Dec 2015 04:58
- Forum: dbExpress driver for Oracle
- Topic: Access violation at address 07F132BF in module 'dbexpoda40.dll'
- Replies: 3
- Views: 12503
Re: Access violation at address 07F132BF in module 'dbexpoda40.dll'
OCI mode. The error occurs either when closing a TClientDataSet or while applying some updates in a TClientDataSet.
- Fri 18 Dec 2015 01:37
- Forum: dbExpress driver for Oracle
- Topic: running side by side apps with different versions of the devart dbexpress oracle driver?
- Replies: 1
- Views: 5782
running side by side apps with different versions of the devart dbexpress oracle driver?
We have a requirement where we might have to run two versions of the same app on the same workstation. The problem is that one version uses version 6.3.6 of the Devart dbexpress oracle driver, and the other one uses version 6.7.10.
Is it doable? Our setup puts the dbexpoda40.dll to the c:\windows\system32 directory.
Thank you
Is it doable? Our setup puts the dbexpoda40.dll to the c:\windows\system32 directory.
Thank you
- Fri 18 Dec 2015 00:46
- Forum: dbExpress driver for Oracle
- Topic: Access violation at address 07F132BF in module 'dbexpoda40.dll'
- Replies: 3
- Views: 12503
Access violation at address 07F132BF in module 'dbexpoda40.dll'
Hi, guys:
Our app (32 bit) uses Delphi XE5, devart dbexpress driver for Oracle version 6.3.6, Oracle 10g.
I don't have too much information on this one, but one of our users got this access violation. I tried to reproduce it in my own development environment but I could not. In production they use the application over Terminal Services on a windows 2008 server.
My question to you is this: in your experience did you see any issues running apps over terminal services?
I know I provide close to nothing information , but I was curious to see if you've seen issues related to the fact that the apps were running over terminal services, which means the same oracle client is used by multiple users at the same time. One would think it should not have an effect but you never know.
Thanks
Our app (32 bit) uses Delphi XE5, devart dbexpress driver for Oracle version 6.3.6, Oracle 10g.
I don't have too much information on this one, but one of our users got this access violation. I tried to reproduce it in my own development environment but I could not. In production they use the application over Terminal Services on a windows 2008 server.
My question to you is this: in your experience did you see any issues running apps over terminal services?
I know I provide close to nothing information , but I was curious to see if you've seen issues related to the fact that the apps were running over terminal services, which means the same oracle client is used by multiple users at the same time. One would think it should not have an effect but you never know.
Thanks
- Fri 11 Sep 2015 18:03
- Forum: dbExpress driver for Oracle
- Topic: Exception class EDatabaseError with message 'qryTest: Type mismatch for field 'KEY', expecting: FMTBcdField
- Replies: 4
- Views: 5350
Re: Exception class EDatabaseError with message 'qryTest: Type mismatch for field 'KEY', expecting: FMTBcdField
Hey:
I reproduced this issue for you in a separate sample than our app. Here is all the information:
- Oracle 10g version: 10.2.0.4.0 32 bit running on linux RH
- Oracle 12c version: 12.1.0.2.0 64 bit running on Oracle Linux 7
- devart dbexpress Oracle driver 6.6.9
- windows app 32 bit
- Delphi XE8 SP1 running onw windows 7 64 bit SP1
This is the sql that you have to run in both databases before you run the test app:
This particular sql view is contrived however it mirrors somewhat the production code.
- You need to add this in the dbxconnections.ini (add the name of your db and your user name - start with Oracle 10g):
- Delphi code:
MainUnit.dfm (replace xxx with the proper information):
MainUnit.pas:
I haven't added the project dpr and droj files but basically I created a VCL forms application.
The crux of the issue is that, when using 10g and adding adding all fields to the TSQLQuery component, the driver stores the precision of the VAL column as 32! And here is the interesting thing. It is because of the WITH clause in the view. If you re-write the view query without the with clause, the precision/scale are detected properly, i.e. 2/0. In 12c apparently they fixed it and it works even with the WITH clause.
One more thing, when you test adding the field to the TSQLQuery component make sure you disconnect the TSQLConnection object first. It seems that Delphi caches the field and it doesn't really re-retrieve the field meta-data from the database.
Let me know if now you can reproduce the issue, otherwise I will provide more information if you need it.
Thanks
I reproduced this issue for you in a separate sample than our app. Here is all the information:
- Oracle 10g version: 10.2.0.4.0 32 bit running on linux RH
- Oracle 12c version: 12.1.0.2.0 64 bit running on Oracle Linux 7
- devart dbexpress Oracle driver 6.6.9
- windows app 32 bit
- Delphi XE8 SP1 running onw windows 7 64 bit SP1
This is the sql that you have to run in both databases before you run the test app:
Code: Select all
--drop table TEST_CODE1_TB;
--drop table TEST_CODE2_TB;
create table TEST_CODE1_TB (CD NUMBER(2) NULL);
create table TEST_CODE2_TB (CD NUMBER(2) NULL);
INSERT INTO TEST_CODE1_TB VALUES(-20);
INSERT INTO TEST_CODE2_TB VALUES(-10);
COMMIT;
-- drop public synonym TEST_CODE_TB_SYN;
create or replace view test_code_v
as
with x as (
select * from TEST_CODE2_TB
)
SELECT CAST(
(CASE
WHEN T1.CD < 0 THEN T1.CD
when t1.cd = 0 then t2.cd
when t1.cd < 10 then null
ELSE cast('-1' as number(2))
END) AS NUMBER(2)) AS Val
FROM TEST_CODE1_TB T1 cross join x T2;
- You need to add this in the dbxconnections.ini (add the name of your db and your user name - start with Oracle 10g):
Code: Select all
[TestDB]
BlobSize=-1
DataBase=<tnsnames.ora entry>
DriverName=DevartOracle
ErrorResourceFile=
LocaleCode=0000
Password=
Oracle TransIsolation=ReadCommitted
RoleName=Normal
User_Name=<user name>
LongStrings=True
EnableBCD=True
InternalName=
FetchAll=False
CharLength=0
Charset=
UseQuoteChar=False
UseUnicode=True
MainUnit.dfm (replace xxx with the proper information):
Code: Select all
object Form1: TForm1
Left = 0
Top = 0
Caption = 'Form1'
ClientHeight = 412
ClientWidth = 852
Color = clBtnFace
Font.Charset = DEFAULT_CHARSET
Font.Color = clWindowText
Font.Height = -11
Font.Name = 'Tahoma'
Font.Style = []
OldCreateOrder = False
OnCreate = FormCreate
PixelsPerInch = 96
TextHeight = 13
object DBGrid1: TDBGrid
Left = 288
Top = 64
Width = 320
Height = 120
DataSource = DataSource1
TabOrder = 0
TitleFont.Charset = DEFAULT_CHARSET
TitleFont.Color = clWindowText
TitleFont.Height = -11
TitleFont.Name = 'Tahoma'
TitleFont.Style = []
end
object SQLQuery1: TSQLQuery
MaxBlobSize = -1
Params = <>
SQL.Strings = (
'select * from test_code_v')
SQLConnection = SQLConnection1
Left = 56
Top = 344
object SQLQuery1VAL: TFMTBCDField
FieldName = 'VAL'
Precision = 32
end
end
object DataSource1: TDataSource
DataSet = ClientDataSet1
Left = 80
Top = 160
end
object DataSetProvider1: TDataSetProvider
DataSet = SQLQuery1
Left = 80
Top = 272
end
object ClientDataSet1: TClientDataSet
Aggregates = <>
Params = <>
ProviderName = 'DataSetProvider1'
Left = 80
Top = 216
end
object SQLConnection1: TSQLConnection
ConnectionName = 'TestDB'
DriverName = 'DevartOracle'
Params.Strings = (
'BlobSize=-1'
'DataBase=xxx'
'DriverName=DevartOracle'
'ErrorResourceFile='
'LocaleCode=0000'
'Password='
'Oracle TransIsolation=ReadCommitted'
'RoleName=Normal'
'User_Name=xxx'
'LongStrings=True'
'EnableBCD=True'
'InternalName='
'FetchAll=False'
'CharLength=0'
'Charset='
'UseQuoteChar=False'
'UseUnicode=True')
Connected = True
Left = 80
Top = 104
end
end
Code: Select all
unit MainUnit;
interface
uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, DBXDevartOracle, Data.DB, Data.SqlExpr, Data.FMTBcd, Vcl.Grids, Vcl.DBGrids,
Datasnap.DBClient, Datasnap.Provider;
type
TForm1 = class(TForm)
SQLQuery1: TSQLQuery;
DataSource1: TDataSource;
DataSetProvider1: TDataSetProvider;
ClientDataSet1: TClientDataSet;
DBGrid1: TDBGrid;
SQLConnection1: TSQLConnection;
SQLQuery1VAL: TFMTBCDField;
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.FormCreate(Sender: TObject);
begin
SQLConnection1.Connected := true;
ClientDataSet1.Active := true;
end;
end.
The crux of the issue is that, when using 10g and adding adding all fields to the TSQLQuery component, the driver stores the precision of the VAL column as 32! And here is the interesting thing. It is because of the WITH clause in the view. If you re-write the view query without the with clause, the precision/scale are detected properly, i.e. 2/0. In 12c apparently they fixed it and it works even with the WITH clause.
One more thing, when you test adding the field to the TSQLQuery component make sure you disconnect the TSQLConnection object first. It seems that Delphi caches the field and it doesn't really re-retrieve the field meta-data from the database.
Let me know if now you can reproduce the issue, otherwise I will provide more information if you need it.
Thanks
- Thu 10 Sep 2015 23:57
- Forum: dbExpress driver for Oracle
- Topic: Exception class EDatabaseError with message 'qryTest: Type mismatch for field 'KEY', expecting: FMTBcdField
- Replies: 4
- Views: 5350
Re: Exception class EDatabaseError with message 'qryTest: Type mismatch for field 'KEY', expecting: FMTBcdField
Just an update, it seems that changing the type to TBCDField and adding the Precision and Size types manually in the dfm file fixes the issue. However, now when I try to connect to Oracle 10g I get an error because it is expecting TFMTBCDField!
What I think it happens is that in Oracle 12c the meta-data returns the correct precision/size for the column while in 10g it doesn't. Before the change, the Precision was 32! Interesting enough, the column comes from a view and it is computed through a case statement expression, however, it is cast to NUMBER(2).
Any other ideas?
What I think it happens is that in Oracle 12c the meta-data returns the correct precision/size for the column while in 10g it doesn't. Before the change, the Precision was 32! Interesting enough, the column comes from a view and it is computed through a case statement expression, however, it is cast to NUMBER(2).
Any other ideas?
- Thu 10 Sep 2015 23:13
- Forum: dbExpress driver for Oracle
- Topic: Exception class EDatabaseError with message 'qryTest: Type mismatch for field 'KEY', expecting: FMTBcdField
- Replies: 4
- Views: 5350
Exception class EDatabaseError with message 'qryTest: Type mismatch for field 'KEY', expecting: FMTBcdField
Hello:
I am having the issue described here: http://forums.devart.com/viewtopic.php?t=20209.
I am using the 6.6.9 version of the driver, Delphi XE8. The same app, when connected to an Oracle 10g database works fine but when connected to an Oracle 12c it barfs on a NUMBER(2) field with the error in the title.
Is there a solution to this, other than refreshing the fields for each dataset that has this issue?
Why is this inconsistency?
Thanks!
I am having the issue described here: http://forums.devart.com/viewtopic.php?t=20209.
I am using the 6.6.9 version of the driver, Delphi XE8. The same app, when connected to an Oracle 10g database works fine but when connected to an Oracle 12c it barfs on a NUMBER(2) field with the error in the title.
Is there a solution to this, other than refreshing the fields for each dataset that has this issue?
Why is this inconsistency?
Thanks!
- Mon 21 Apr 2014 22:45
- Forum: dbExpress driver for Oracle
- Topic: devart driver runs an extra child query
- Replies: 0
- Views: 2404
devart driver runs an extra child query
Hello:
To test reproduce this issue please use this project: https://dl.dropboxusercontent.com/u/353 ... lity01.zip. I used XE5 and the latest version of the devart dbexpress driver for oracle (6.3.6).
These are the steps:
1. Open the project in XE5. Modify the connection properties to point to your own oracle database. The queries don't need any table and they create rows on the fly. You may also have to reconfigure the location of the sql monitor trace file.
2. Open dbmonitor (the tool from your site that comes with the driver).
3. Run the project.
4. Go to the dbmonitor window. There is an extra query to retrieve child records. See the screenshot below and the selected query. The parameter value is 0 which is the value that was set at design time. This query is redundant. If you change the driver to the dbexpress Oracle driver you'll notice that no such query is executed (check the c:\temp\dbexpress_log.txt file, that is the sql monitor trace file). The next query retrieves the child data associated with the first row (parent id=1).
When you have lots of child datasets the driver will execute a dummy query for each child dataset which can affect the performance of the application.
What can be done to get rid of this redundant query?
One more thing to add, the query for the child dataset in this sample project is contrived, in the real app it has the pattern: select * from some_view where parent_id = :ID.
Thanks
To test reproduce this issue please use this project: https://dl.dropboxusercontent.com/u/353 ... lity01.zip. I used XE5 and the latest version of the devart dbexpress driver for oracle (6.3.6).
These are the steps:
1. Open the project in XE5. Modify the connection properties to point to your own oracle database. The queries don't need any table and they create rows on the fly. You may also have to reconfigure the location of the sql monitor trace file.
2. Open dbmonitor (the tool from your site that comes with the driver).
3. Run the project.
4. Go to the dbmonitor window. There is an extra query to retrieve child records. See the screenshot below and the selected query. The parameter value is 0 which is the value that was set at design time. This query is redundant. If you change the driver to the dbexpress Oracle driver you'll notice that no such query is executed (check the c:\temp\dbexpress_log.txt file, that is the sql monitor trace file). The next query retrieves the child data associated with the first row (parent id=1).
When you have lots of child datasets the driver will execute a dummy query for each child dataset which can affect the performance of the application.
What can be done to get rid of this redundant query?
One more thing to add, the query for the child dataset in this sample project is contrived, in the real app it has the pattern: select * from some_view where parent_id = :ID.
Thanks
- Wed 12 Mar 2014 00:17
- Forum: dbExpress driver for Oracle
- Topic: What is a cursor in the dbMonitor Object tree?
- Replies: 4
- Views: 3281
Re: What is a cursor in the dbMonitor Object tree?
I don't have anything to add to this. My questions required some clarification about what we see in the dbmonitor.
- Wed 12 Mar 2014 00:16
- Forum: dbExpress driver for Oracle
- Topic: Passing array to a stored procedure
- Replies: 12
- Views: 6244
Re: Passing array to a stored procedure
Alex, could you please be more specific, what is exactly that the dbexpress technology is restricting or it doesn't support?
Thank you
Thank you
- Tue 04 Mar 2014 02:21
- Forum: dbExpress driver for Oracle
- Topic: Passing array to a stored procedure
- Replies: 12
- Views: 6244
Re: Passing array to a stored procedure
I read the source code and I don't think it is supported. I basically looked at TCRSQLCommand.setParamDescValue. It doesn't handle the dtTable type parameters.
But how hard can it be to add support for TABLE types? The TOCIMetaData.GetProcedureParameters returns the type of table for Table type parameters. Is there anything else needed?
I would like to use this thread to request support for this type of parameters.
Thanks
But how hard can it be to add support for TABLE types? The TOCIMetaData.GetProcedureParameters returns the type of table for Table type parameters. Is there anything else needed?
I would like to use this thread to request support for this type of parameters.
Thanks
- Tue 04 Mar 2014 01:23
- Forum: dbExpress driver for Oracle
- Topic: Passing array to a stored procedure
- Replies: 12
- Views: 6244
Re: Passing array to a stored procedure
Are table types such as "...type table of number" still not supported as parameters (in the dbexpress driver)?
If they are supported, could you please provide a sample? What data type should be used to populate the parameter?
Thank you
If they are supported, could you please provide a sample? What data type should be used to populate the parameter?
Thank you
- Fri 21 Feb 2014 22:40
- Forum: dbExpress driver for Oracle
- Topic: What is a cursor in the dbMonitor Object tree?
- Replies: 4
- Views: 3281
What is a cursor in the dbMonitor Object tree?
Hi:
What are these cursor objects that are displayed under the connection object in the Object tree?
I assumed that the Connection node (in the Object Tree) corresponds to the TSQLConnection object in the app. I am however confused by the Cursor objects.
I have the following scenario:
1. Connect to oracle as user1
2. Run query1 (using TSQLStoredProc)
3. Disconnect
4. Connect to oracle as user2 using the same TSQLConnection object as at step 1
5. Run query2 (using TSQLQuery)
In the dbMonitor query1 & query2 appear associated with the same cursor. I found this confusing and I was hoping that you could clarify what a cursor is in this context and why two queries run in different sessions appear under the same cursor. The cursors in the dbMonitor doesn't seem to correlate with the information returned by the v$open_cursor view.
I also looked in the dbMonitor help and there is no specification of cursors.
Thanks!
Update: After more testing with a second app in debug mode, the dbmonitor created a second connection object, even though we use a single TSQLConnection object. So, at this point, I am not sure the Connection nodes in the Object tree map to the TSQLConnection object.
What are these cursor objects that are displayed under the connection object in the Object tree?
I assumed that the Connection node (in the Object Tree) corresponds to the TSQLConnection object in the app. I am however confused by the Cursor objects.
I have the following scenario:
1. Connect to oracle as user1
2. Run query1 (using TSQLStoredProc)
3. Disconnect
4. Connect to oracle as user2 using the same TSQLConnection object as at step 1
5. Run query2 (using TSQLQuery)
In the dbMonitor query1 & query2 appear associated with the same cursor. I found this confusing and I was hoping that you could clarify what a cursor is in this context and why two queries run in different sessions appear under the same cursor. The cursors in the dbMonitor doesn't seem to correlate with the information returned by the v$open_cursor view.
I also looked in the dbMonitor help and there is no specification of cursors.
Thanks!
Update: After more testing with a second app in debug mode, the dbmonitor created a second connection object, even though we use a single TSQLConnection object. So, at this point, I am not sure the Connection nodes in the Object tree map to the TSQLConnection object.
- Fri 31 Jan 2014 18:58
- Forum: dbExpress driver for Oracle
- Topic: vcl app not exiting upon closing the main form
- Replies: 9
- Views: 4447
Re: vcl app not exiting upon closing the main form
Hello:
We made a slight change to the app which makes more reproducible. You can get it here: https://dl.dropboxusercontent.com/u/353 ... tError.zip
I also included a screenshot of the delphi IDE so you can see the error.
Again this error has something to do with the TSQLMonitor object. If it is disconnected from the connection, the app always exists.
Could you please investigate and don't give up on this?
We made a slight change to the app which makes more reproducible. You can get it here: https://dl.dropboxusercontent.com/u/353 ... tError.zip
I also included a screenshot of the delphi IDE so you can see the error.
Again this error has something to do with the TSQLMonitor object. If it is disconnected from the connection, the app always exists.
Could you please investigate and don't give up on this?
- Thu 30 Jan 2014 20:41
- Forum: dbExpress driver for Oracle
- Topic: vcl app not exiting upon closing the main form
- Replies: 9
- Views: 4447
Re: vcl app not exiting upon closing the main form
The problem is that this issue is intermittent, it doesn't always occur and that's what's making it frustrating. That's why I suggested that you patiently try it multiple times if the error doesn't occur the first time.
Just curious, what operating system did you use, and did you try to test using the same versions of the driver? We develop using Windows 7 64 bit and the target app is 32 bit.
Just curious, what operating system did you use, and did you try to test using the same versions of the driver? We develop using Windows 7 64 bit and the target app is 32 bit.
- Wed 29 Jan 2014 23:48
- Forum: dbExpress driver for Oracle
- Topic: vcl app not exiting upon closing the main form
- Replies: 9
- Views: 4447
Re: vcl app not exiting upon closing the main form
Hello:
Here is a project that you can use to reproduce this: https://dl.dropboxusercontent.com/u/353 ... tError.rar.
Please note the following:
Thanks
Here is a project that you can use to reproduce this: https://dl.dropboxusercontent.com/u/353 ... tError.rar.
Please note the following:
- - I used XE5 Update 2, version 6.3.4 of the devart dbexpress oracle driver, and version 11.2.0 of the oracle client (the version of the oci.dll is 11.2.0.1)
- before you run the project you need to update the connection information
- The issue occurs intermittently, but to reproduce it quicker, you need to run the app in debug mode. I also had the devart dbmonitor app running to see what was executed. After the main window is visible and the grid has data, click on the Refresh button multiple times (I clicked, for instance, 11 times) then close the window (after waiting for the queries to be done). Sometimes the application hangs even though the main window was closed. Go to View->Debug Windows->Threads. One of the threads in the window will be blocked. Double-click on the thread to view the stack trace.
Thanks