SourceDataSets

Discussion of open issues, suggestions and bugs regarding Virtual Data Access Components for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
Aggie85
Posts: 95
Joined: Wed 11 Nov 2015 17:03

SourceDataSets

Post by Aggie85 » Fri 07 Jul 2017 04:06

Maxim,

Could you please clear up an issue I am having with TVirtualQuery.

In TxQuery and TkbmMemSQL, I can add all the source dataset aliases and then issue as many SQL statements as I want against the query object (only the datasets referenced in the applied SQL statement are used).

When I try the above approach with TVirtualQuery, I get all kinds of errors. If I only add the datasets referenced in the SQL statement, no errors occur.

Is this correct?

Thanks,

Aggie85

MaximG
Devart Team
Posts: 1822
Joined: Mon 06 Jul 2015 11:34

Re: SourceDataSets

Post by MaximG » Fri 07 Jul 2017 14:27

You are absolutely right. This behavior is correct. Before opening a query in VirtualQuery, all datasets used in the query must be active. In case when at least one of these sets is not active, when opening VirtualQuery you will receive the message: "Source dataset is not active" Please specify which error messages you receive in this case.

Aggie85
Posts: 95
Joined: Wed 11 Nov 2015 17:03

Re: SourceDataSets

Post by Aggie85 » Fri 07 Jul 2017 15:30

Howdy Maxim!

That is NOT the problem I am having. All the datasets are active, but I get strange errors like "vtable contructor blah...blah on <table name>" and the <table name> isn't used in the query.

It seems (not enough testing yet) that if I only add the data sets being used in the SQL statement, I never see unexpected results.

Just looking if this is a bug or misuse on my part.

Have a great weekend,

Aggie85

MaximG
Devart Team
Posts: 1822
Joined: Mon 06 Jul 2015 11:34

Re: SourceDataSets

Post by MaximG » Mon 10 Jul 2017 08:32

We continue testing VirtualDAC using the night build of these components. However, we cannot get the described errors. Please specify whether these errors occur when using a release version or the sent night build of VirtualDAC ? Please compose and send us via the e-support form ( https://www.devart.com the "Support"\"Request Support" menu) a small sample in which the problem occurs.

Aggie85
Posts: 95
Joined: Wed 11 Nov 2015 17:03

Re: SourceDataSets

Post by Aggie85 » Mon 10 Jul 2017 08:38

Good morning Maxim!

I am changing the way I use TVirtualQuery to individual cases; that is, I am now setting it up for each use instead of trying to set it up once with all the Source Data Sets.

I am still doing testing to see if this resolves my problems.

So far the only thing I am seeing with my regression testing is that JOINS are still slow compared to TxQuery. The problem seems to be in the retrieval of data with TVirtualQuery.

All the best,

Aggie85

MaximG
Devart Team
Posts: 1822
Joined: Mon 06 Jul 2015 11:34

Re: SourceDataSets

Post by MaximG » Tue 11 Jul 2017 13:20

We received the sent sample and investigated its work. You are absolutely right - the cause of the specified error is the name of the ”UNIQUE” field. The ”UNIQUE” name is a reserved word for SQLite engine (http://www.sqlite.org/lang_keywords.html) used by us in VirtualDAC . Therefore, you cannot use dataset fields with this name. We will add the ”UNIQUE” value to the reserved words list of our product in the next build.

Aggie85
Posts: 95
Joined: Wed 11 Nov 2015 17:03

Re: SourceDataSets

Post by Aggie85 » Tue 11 Jul 2017 14:33

Thanks for the great support!

Aggie85

MaximG
Devart Team
Posts: 1822
Joined: Mon 06 Jul 2015 11:34

Re: SourceDataSets

Post by MaximG » Wed 12 Jul 2017 08:23

We are glad that we could help you in the issue solution.

Post Reply