BorlandTalk.com

K-Man · Guest

IB 6.Open (6.0.2.0)

Midas file version: 7.1.1692.666

Midas.dll bug:

While scrolling through records of the
table defined below:

CREATE TABLE "CRD_FRQ"
(
"FIRST_NMBR" NUMERIC(18, 0) NOT NULL,
"SECON_NMBR" NUMERIC(18, 0) NOT NULL,
"TRG_TYP" VARCHAR(50) NOT NULL,
"UNIT_NM" VARCHAR(25) NOT NULL,
"QTY" INTEGER,
"BA5EVAL" VARCHAR(35),
"BVRTYP" "MY_DOMAIN",
"BVTINT" INTEGER,
"BV6DT" DATE,
"BVTCRD" VARCHAR(25),
"EXE45PRTY" "ANOTHER_DOMAIN",
"NMBR10" VARCHAR(25),
"CAD14" VARCHAR(25),
"STATUS" "NEXT_DOMAIN",
"IRDTX" VARCHAR(35),
CONSTRAINT "PK_FIRST_NMBR" PRIMARY KEY ("FIRST_NMBR", "SECON_NMBR"),
CONSTRAINT "UNQ_SECON_NMBR" UNIQUE ("SECON_NMBR")
);

I will get the following error only on certain records:

---------------------------
Debugger Exception Notification
---------------------------
Project my_client.exe raised exception class EAccessViolation
with message 'Access violation at address 0053AA77 in module
'my_client.exe'. Read of address 0000011B'. Process stopped.
Use Step or Run to continue.
---------------------------
OK Help
---------------------------

The error occurs only on specific records, but there is no
discernable pattern to the "bad" records versus the "good"
records. I can use my client to create records, but then
I ApplyUpdates, which works OK, I then do a Refresh. The
error always occurs either on the TClientDataSet.Open, or
on the refresh. Midas allows me to create the record but
I can't get to it immediately after wards.

Using IB console I can read the records in the table without
a problem.

I just upgraded my entire project from D6 Enterprise. Under
D6, same back end, I had no midas problems what so ever. I
have made no code changes nor database changes since the
upgrade.

The error occurs with or without the term "MidasLib" in the
"uses" clause.

Can anyone help me work around this bug?

Thanks in advance.

K-Man · Guest

More on this bug:

Midas is unable to read more than one record from the table. If I use
IBConsole to delete all records from the table, I can use my client to
add one record. The post, and ApplyChanges goes through ok. When I
use my client to add a second record, a "key violation" error shows up
on .Refresh of the TClientDataSet. I then close my detail table
within the client, then open it and then, upon trying to open, the
previously mentioned error occurs.

At this point, I examine the table from within IBConsole, and
determine that the record was indeed INSERTed correctly into IB. IB
doesn't report a key violation, nor any other problem. I can use IB
Console to add records as I wish, following of course the primary key
constraint, and the records get added ok.

There is no difference between the "good" records and "bad" records.
It appears that the problem occurs if there is *more than one record*
in this particular table with the same PAR_RID. (TRK_RIDs are always
different, they are added by trigger at BEFORE INSERT) (This is a
detail table)

Evidence still points to a "Midas in D7" problem.

I was hoping to get help from the midas experts soon on this as my
project is held up until I get this solved. If not, my develoment
team is stuck in D6 and thereby I can't recommend to my company
(military customer) that we invest in D7 or D8.

Thanks in advance.

K-Man · Guest

SLAMMED THAT BUG!

To re-create this bug:

-----------------------------------

On AppServer:

The provider used by the client's TClientDataSet must have the
following settings:

Constraints: True
UpdateMode: upWhereAll

The persistent key fields in the query (IOW: the field objects
representing the Primary Key of the IB table) must have their
ProviderFlags set to:

pfInUpdate, pfInWhere, pfInKey

-----------------------------------

So far so good. These are the normal settings you would expect. Now,
onto the Client...

-----------------------------------

On the client:

In the TClientDataSet, the corresponding fields of the primary key
fields would normally default to only:

pfInUpdate, pfInWhere

My understanding of how the provider works, is that the provider will
"hand off" the ProviderFlags settings to the persistent fields on the
client. So, the client's persistent fields will 'adopt' the
pfInUpdate, pfInWhere, and, in this case, the pfInKey as well, *at run
time*.

At this point, my application works correctly. To cause the bug in
question, proceed to:

On the client add the pfInKey to the two persistent field objects
representing the primary key.

Do a compile all and run the application.

This is 100% repeatable. This bug does not occur on the D6 version of
Midas.Dll (on my D6 machine)

The bug is manifested by:

a) Not all the records in the database will come through to the
client, only the first one.
b) Any attempt to add a record will cause a memory access error
reporting Midas.Dll as the culprit.

-----------------------------------

Bug report closed.

K-Man · Guest

On Thu, 08 Jul 2004 22:19:46 GMT, [email]kandw321 (AT) icrossroads (DOT) com[/email] (K-Man)
wrote:

K-Man · Guest

I accidentally re-quoted the entire original message text in my last
post. Sorry about that. I couldn't see it in my news reader above my
control bar.

K-Man · Guest

I did some more testing on subject bug. It turns out that the problem
can be created a different way than from what I originally found.

To create the bug:

Assume there are six records that satisfy the WHERE clause in the
table. Assume that IRDTX contains a different value for each of the
six records.

In the TRemoteDataModule, in theTSQLQuery type an appropriate SQL
like:

SELECT * FROM CRD_FRQ WHERE FIRST_NMBR = 234O
ORDER BY IRDTX {<== Notice that IRDTX is a VARCHAR(35)}

Recompile the TRemoteDataModle then, using the client exe, open the
TClientDataSet that is connected to the TDataSetProvider that is
connected to the SQLQuery.

The number of records returned will be erroneous. It will be one, or
two, not all six.

------------------------------- To clear this bug

In the TRemoteDataModule, change the SQL to:

SELECT * FROM CRD_FRQ WHERE FIRST_NMBR = 234O
ORDER BY FIRST_NMBR {<== Notice that this field is an integer}

or, drop the ORDER BY altogether:

SELECT * FROM CRD_FRQ WHERE FIRST_NMBR = 234O

In both of the above cases, the number of records returned to the
client exe will be correct and in the correct order.

---------------------------------

Conclusion:

Something in Midas.Dll is not able to deal with ORDER BY clauses that
reference a VARCHAR() field. It only works correctly with no ORDER BY
clause, or ORDER BY on an INTEGER field.

It is definatel not a TSQLQuery problem as I wrote a tiny method in
the TLB to count the records from the TSQLQuery after open. It always
reported the correct number of records (6) no matter what ORDER BY was
doing. Something downstream from the TSQLQuery was scrambling the
data as it was being transported to the client exe.

So, now I need help. Anyone got an answer how I can fix this?
I must have the ORDER BY working, just like in D6 or my project is
stalled.

Thanks in advance.

K-man · Guest

In the dbExpress ng I found the following possible solutions:

a) In the TDataSetProvider, set RetainServerOrder to TRUE
b) Apply hack in QC 7790

I will try them out.

Mark Edington (Borland) · Guest

"K-Man" <kandw321 (AT) icrossroads (DOT) com> wrote

K-man · Guest

Thanks for the respnonse Mark. I changed my 'Retain
ServerOrder" to True and it cured the problem. The reason I thought
it was a bug is because in D6 one did not have to do this. I thought
that using strictly Borland VCL components would give me the fewest
upgrade head aches.

This seems to be a very quite group. Relatively few answers/help
posted.