Anyone there?upscene wrote:Any news?Challenger wrote:I have filled table with 1 mln records and created a select statement with cross join. I have executed and fetched this statement and checked the DatabaseInfo.Reads parameter. It gave 130000. The same value I saw in IBConsole. I had the same value in Delphi 7 and Delphi 2009 regardless the Unicode option.
Here is the information from the Info page of the TIBCConnection editor:Can try the same test with IBX components? You can check the length of this parameter in the TIBDatabaseInfo.GetLongDatabaseInfo method (the IBDatabaseInfo unit).Code: Select all
Server Version: WI-V9.0.3.437 Client Version: 9.0 ODS Version: 13.1 Client Library: D:\Program Files\InterBase\bin\gds32.dll Database SQL Dialect: 3
TIBCConnection.DatabaseInfo faulty results with Unicode
Here's a screenshot of a test project, the above part has IBX (v12.12) components, the memo simply holds the output of IBDatabaseInfo.ReadIdxCount (before and after the Query.Open & FetchAll calls). Database has WIN1251 charset, in IBDac, UseUnicode is OFF, all other options (except "FetchAll") are default, using Firebird 2.1.1Dimon wrote:I still can not reproduce the problem. Did you try the same test with IBX components?
The bottom part has IBDac (v3.10.0.12) components, as you can see, the values of the tables are very different -> 2 byte values (they are even wrapped over the 2 byte boundary!!)
For example, take the values of table 160:
IBX: 138859 ($21E6B)
IBDac: 7787 ($1E6B)
Here's the code:
Code: Select all
procedure TForm20.Button1Click(Sender: TObject);
begin
IBDatabase1.Open;
Memo1.Lines.AddStrings(IBDatabaseInfo1.ReadIdxCount);
IBQuery1.Open;
IBQuery1.FetchAll;
Memo1.Lines.AddStrings(IBDatabaseInfo1.ReadIdxCount);
end;
procedure TForm20.Button2Click(Sender: TObject);
begin
IBCConnection1.Open;
Memo2.Lines.AddStrings(IBCConnection1.DatabaseInfo.ReadIdxCount);
IBCQuery1.Open;
Memo2.Lines.AddStrings(IBCConnection1.DatabaseInfo.ReadIdxCount);
end;Please respond as soon as possible, I don't want to wait another week between answers...
Hello,
I use other vcl components and generally the delay for an answer is several hours.
I have to buy other VCL components for Database and i am not sure to buy them with Devart. I think they have good components but the problem above is important.
Regards
I agree with you upscene. The delay between questions and answers is too long. When we are blocked in our code waiting tow business days is too much.Please respond as soon as possible, I don't want to wait another week between answers...
I use other vcl components and generally the delay for an answer is several hours.
I have to buy other VCL components for Database and i am not sure to buy them with Devart. I think they have good components but the problem above is important.
Regards
-
Challenger
- Devart Team
- Posts: 925
- Joined: Thu 17 Nov 2005 10:53
The notification from our forum were missed so I missed your reply. Sorry. I have eventually reproduced and fixed this problem. This problem concerns parameters that return TStringList as result. It seems that we were talking about different parameters. So please try to compose a small sample next time. This may reduce time.
Challenger wrote: This problem concerns parameters that return TStringList as result. It seems that we were talking about different parameters.
And later on, I gave you a complete table with values... Where else do these values come from?upscene wrote:Using the latest IBDac, the properties on Indexed Reads and so on don't return the correct values -> I compared these with IBObjects. Also, given the number of rows in the tables, these values were simply too small.Dimon wrote:We still can not reproduce the problem. Please specify the IBDAC version you are using and property that returns a wrong result.
As for a test project, I told you I couldn't forward you this customer database...Good to hear you finally fixed this problem, when can we except an update?
FYI, Firebird 2.5 uses INT64 for statistics, see the Release Notes, chapter "Changes to the Firebird Engine". I'm not sure if this only works with fbclient.dll from Firebird 2.5 or that an older client can be mixed with server 2.5, it says:Challenger wrote:The notification from our forum were missed so I missed your reply. Sorry. I have eventually reproduced and fixed this problem. This problem concerns parameters that return TStringList as result. It seems that we were talking about different parameters. So please try to compose a small sample next time. This may reduce time.
Statistics Now Work Properly with 64-bit Values
V. Khorsun
A. Peshkov
Tracker reference CORE-2619
Changes in the Firebird Engine
Memory and other statistics did not work properly 64-bit values in older Firebird versions. The issue had two
parts:
a. To make the engine use 64-bit integers for statistics, the internals of AtomicCounter were changed.
b. The isql and qli tools had to be taught to work with 64-bit values.
Incompatibility with Older Clients
To enable the 32-bit tools to work correctly with a 64-bit server, it was necessary to introduce some new internal
API functions (struct perf64 and perf64_xxx) and change isql and qli to use them. This means that the isql
and qli programs in V.2.5 are not compatible with older Firebird clients.
