BorlandTalk.com

Tom Conlon · Guest

1. How bug-ridden is DBExpress + is it usuable for serious apps?
2. As BDE is now deprecated why has not DBX made bullet-proof?
3. If DBX buggy, I have D6 UP2 Enterprise, what position does that leave in
relation to getting updated drivers that do what they purport to do?
4. Anyone writtten serious multi-tier apps with MIDAS? If so, how many users
+ what connection component?

Thanks,
Tom

Craig Stuntz [TeamB] · Guest

Tom Conlon wrote:

Ramesh Theivendran · Guest

Here is the list of dbExpress bugs that got addressed in DELPHI 8 for .NET.
There are plans to make these fixes available to D7 WIN32 as well.

A. DB2 bugs in QC:
-------------------------
1. DB2 V8 Support 4150 - FIXED.
dbExpress driver metadata to provide support for DB2 V8:
Querying a table with unique fields returns the error "Could not convert
variant of type (Null) into type (String)."

2.Fetching Stored Procedure parameters fails. - FIXED.

B. MySQL Bugs in QC:
-----------------------------
1.3731 - FIXED
2. MySQL Port - Support added

3.4504 - FIXED

4.1810 - Data truncation (Vendor issue)
MySQL Field.length=1024 for the second columns after describing the SQL
"Show create table tablename"
and that's the reason for truncation.

5. 4689 - Workaround done.
Timestamp comes back as NOT NULL always.(Vendor issue)

Please read the MySQL API documentation

http://www.mysql.com/documentation/mysql/bychapter/manual_Clients.html#C_API_functions

NOT_NULL_FLAG - Field can't be NULL and the flag is set in for all the
following a SELECT is issued on the following 3 tables.

create table testtimestamp1( f1 char(10), fts timestamp)
create table testtimestamp2( f1 char(10), fts timestamp null)
create table testtimestamp3( f1 char(10), fts timestamp not null)

So, there is no distinction between whether a timestamp field is created as
NOT NULL or NOT.
I consider this a MySQL bug. However, a hack has been added to fix this
issue for the time being.

6. QC 4130
7. QC 4160
8. QC 5819.
9. QC 1074. (MySQL Cloning connection issue and transaction rollback - FIXED
In the dbExpress components)

C. MSSQL Bugs in QC:
-----------------------------
1. Stored Procedure with long names - 3225 - FIXED.
2. Resource leakage on repeated execution of SQL - 4059 - FIXED.
3. TimeStamp Fraction rounded while fetching data - FIXED.
4. ExecDirect() not returning the RowsAffected correctly - FIXED.
5. SubQuery parameter binding causes an AV in MSVCRT7.DLL -2767 - MS bug.
Case # SRX030728604937.
6. Null parameter binding on a NOT NULL INTEGER columns fails with a SQL
Error
"SQL State:HY000, SQLError Code:0 Invalid input parameter values" - MS
bug Case #SRX030728605044.

7. MSSQL return parameter not avaliable from a SP returning cursor. -QC #
3763 - FIXED
8. MSSQL SP with no parameters causing a memory corruption - FIXED
9. MSSQL SP not returning @@IDENTITY after a SP execution, you see the
identity value only
on the 3rd execute.- FIXED.

8. MSSQL Transaction failure- MSSQL OLEDB limitation

D. ORACLE Bugs in QC:
-----------------------------

1. QC 4018 - FIXED.
2. QC 4051 - ORACLE Functions support - Feature Added.

E. INTERBASE fixes:
------------------------

1. Added BOOL data type support.

dbExpress Component fixes:
---------------------------------
141766/141772
(QC 1074)
-> Basic problem was that on MySQL every Select has to be executed on a
new SQLConnection.
To do this we clone the connection always, which was wrong. If a
transaction was started
it had to finish on the same connection, no matter what. So this is a big
change to
MySQL and requires a complete re-test of MySQL. This change should not
effect any other
Driver since all others support multiple statements per connection.
-> IF this is verified as fixed the QC bug should get a comment saying
that this issue
will be fixed in Delphi 8

Error handling dbExpress
-> dbExpress would come back in a lot of cases with an error "SQL Error:
Error mapping failed'.
This was basically happening whenever a error number was not in a certain
range of errors.
That means the user would not see the actual SQL error, which most likely
would be more
usefull then this standard error message. This has changed to the fact
that only if there
is no error message at all from a sql server and there is not error
message from the dbx
driver we now display a standard message. This effects all drivers, but it
effects it in
the sence that error messages that come up now may be different. This
can't lead to data
loss or anything else bad ...

174199 -> A select statement on Interbase which had the semicolon at the
end would always fail.
This fix is to remove the semicolon at the end of the SQL. This will be
done for any server
and therefor should be verified on all servers.

174616/178994
(QC 5550) -> This boiled down to a function IsMultiTableQuery() which would
return True eventhough
the SQL statement didn't include 'inner join' or 'outer join'. The fix was
in DBCommon.pas
and effects every driver.

178993
(QC 5465) -> The fix for 141766/141772 should take care of this problem as
well. Has to be verified though.
This is localized to MySQL.

157041
(QC 157041) -> Calculated fields on the first record in MySQL would always
return a blank value. The
fix required to remove a change done to the code specifically for MySQL
and put it into a
different place. This can potentially effect other drivers as well, but if
there was a new
problem introduced we should find it by the generic recertification for
all drivers. I mean
not special testing expect the one for MySQL for this bug fix has to be
done for other drivers.
Master/Detail should be tested.

179226 -> This was a huge performance problem in cases where we would get a
lot of data back. The
fix can effect every driver. Special testing should be done for things
like quoted identifiers,
for example a table name, index name that has a space in it. Also if its
possible to have
the same name twice, whith different casing, then this has to be tested as
well.

TCustomSQLDataSet.PrepareStatement
-> This procedure was protected in under TCustomSqldataset. TSQLQuery and
TTable, which
implement TCustomSqlDataSet expose the procedure as public. Such a thing
is not supported
in .NET. Because of this I made PrePareStatement in VCL and .NET public on
the TCustomSqlDataset
class.

179579 -> This was bascially another cloning issue for MySQL. A "Explicit
Transaction" never worked
under MySQL. Reason was that we were cloning the connection to often. A
Clone of a connection
should only happen for a 'Select ...' statement.

T.Ramesh.
"Tom Conlon" <tomc (AT) gripsystems (DOT) com> wrote

Thomas Miller · Guest

Ramesh,

This list is impressive and I can't wait to get my hands on these.
I didn't see many (if any) meta data fixes. Specifically issues
with Indexes and Primary keys. This is critical for TSQLDataPump
to work properly.

I will make myself available or even write a test program for your
internal people to use to test the meta data part of the dbExpress
drivers.

Thanks.

--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://sourceforge.net/projects/dbexpressplus

Ramesh Theivendran · Guest

Thomas,

Thomas Miller · Guest

Ramesh Theivendran wrote:

vAd · Guest

Hello, Ramesh!
You wrote on Wed, 14 Jan 2004 11:55:56 -0800:

RT> dbExpress Component fixes:
RT> ---------------------------------

RT> 174616/178994 (QC 5550) -> This boiled down to a function
RT> IsMultiTableQuery() which would return True eventhough the SQL
RT> statement didn't include 'inner join' or 'outer join'. The fix was
RT> in DBCommon.pas and effects every driver.

Why you do not wish to take solution QC 6318? It allows to use "select..
from select ..." + unites to IsMultiTableQuery code and GetTableNameFromSQL.

--
Vadim