TIBCQuery change in behaviour

Discussion of open issues, suggestions and bugs regarding IBDAC (InterBase Data Access Components) for Delphi, C++Builder, Lazarus (and FPC)
Post Reply
bzwirs
Posts: 40
Joined: Sat 10 Jul 2010 06:47

TIBCQuery change in behaviour

Post by bzwirs » Sat 24 Jan 2015 03:29

Delphi XE7
Firebird

Have installed latest IBDAC (5.4.13) and found behaviour has changed in TIBCQuery when using 'Applyupdates'.

I have two TIBCQuery's......SaleQry and MachSaleQry both with CachedUpdates = True. SaleQry has an autogenerated key field (by trigger) 'SaleID'.

MachSaleQry has key fields of 'SaleID', 'MachID' and 'ColNum'. So, when I insert a sale record I first assign all the general sale details to the fields in the SaleQry....Post and then ApplyUpdates.

Under all previous versions of IBDAC, this would now allow me to set MachSalesQrySALEID.Value := SaleQrySALEID.Value when applying all the column sale details to MachSaleQry. When all done, I could then check for UpdatesPending and applyupdates before committing all the records. This has been working without any problems for several years.

Now, when I AppyUpdates on SaleQry I get the following error message:

'Violation of FOREIGN KEY constraint on "MACHSALES_1" on table "MACHSALES". Foreign key reference target does not exist. Problematic key value is ("SALEID" = 0).

This same behaviour is also now happening in other areas of the application where the same procedure is followed. Have also tested on other applications and same now happens.

Can you please fix this....I have now had to go back to version 5.4.12 to get my applications to work correctly.

Bill Zwirs

Forgot to mention....When I process the first sale, all works correctly. If I then select a different machine and enter the next sale I then get the error message. When a new machine is selected all is reset as if doing the first sale....and as I have already stated this has worked correctly for several years until this latest IBDAC update (no code has been changed for a very long time in this area of the application).

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Mon 26 Jan 2015 12:59

Unfortunately, we could not reproduce the issue. Please send a small sample to demonstrate the issue to viktorv*devart*com, including a script to create and fill in the test database object.

bzwirs
Posts: 40
Joined: Sat 10 Jul 2010 06:47

Re: TIBCQuery change in behaviour

Post by bzwirs » Tue 27 Jan 2015 08:31

Have discovered that if I refresh the dataset after the applyupdates then all works well. Didn't have to do this before so assume there must be a change in your component code somewhere. Anyway, do I need to go through all my application code to insert Refresh where necessary or will your component be changed back to its original behaviour (if possible).

regards
Bill

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Tue 27 Jan 2015 11:42

IBDAC behavior on executing ApplyUpdates wasn't changed in comparison to the previous version. To solve the problem, try to set the TIBCQuery.DMLRefresh property to True for TIBCQuery components containing an auto-incremental field. More details about thisproerty can be seen at our website: http://www.devart.com/ibdac/docs/devart ... efresh.htm

bzwirs
Posts: 40
Joined: Sat 10 Jul 2010 06:47

Re: TIBCQuery change in behaviour

Post by bzwirs » Tue 27 Jan 2015 19:53

Just tried setting DMLRefresh = True but made no difference. Only seems to work when I use Refresh straight after ApplyUpdates. Tried to create a small sample app yesterday but couldn't get it to duplicate this behaviour. That's when I went back to my app and found that Refresh did the trick.

Not sure if this helps to understand the error but this is the assembler from Eurekalog. Never learnt to read assembler myself but may give you or your people clue.

Assembler Information:
-----------------------------------------------------------------------------------------------------------------------------------------------
; Base Address: $D04000, Allocation Base: $400000, Region Size: 7024640
; Allocation Protect: PAGE_EXECUTE_WRITECOPY, Protect: PAGE_EXECUTE_READ
; State: MEM_COMMIT, Type: MEM_IMAGE
;
;
; IBCClasses.TGDSConnection.IBCError (Line=0 - Offset=122)
; --------------------------------------------------------
00D0470E 33C0 XOR EAX, EAX
00D04710 55 PUSH EBP
00D04711 684847D000 PUSH $D04748 ; ($00D04748->0040AA7C) System._HandleOnException Data as ANSI: 'é/cpÿ.'; Data as UNICODE: '⿩灣ǿ'
00D04716 64FF30 PUSH DWORD PTR FS:[EAX]
00D04719 648920 MOV FS:[EAX], ESP
00D0471C 8B45EC MOV EAX, [EBP-$14]
00D0471F 50 PUSH EAX
00D04720 8B45FC MOV EAX, [EBP-4]
00D04723 50 PUSH EAX
00D04724 8B45F8 MOV EAX, [EBP-8]
00D04727 50 PUSH EAX
00D04728 8BCE MOV ECX, ESI
00D0472A B201 MOV DL, 1
00D0472C A1B400CF00 MOV EAX, [$00CF00B4] ; Data as ANSI: 'è[E'; Data as UNICODE: '寨E完EӀÏӌÏ.'
00D04731 E8B2BCFEFF CALL -$01434E ; ($00CF03E8) IBCError.EIBCError.Create
;
; Line=0 - Offset=162
; -------------------
00D04736 E86D6670FF CALL -$8F9993 ; ($0040ADA8) System._RaiseExcept ; <-- EXCEPTION
00D0473B 33C0 XOR EAX, EAX
00D0473D 5A POP EDX
00D0473E 59 POP ECX
00D0473F 59 POP ECX
00D04740 648910 MOV FS:[EAX], EDX
00D04743 E9A0000000 JMP +$A0 ; ($00D047E8) IBCClasses.TGDSConnection.IBCError (Line=0)
00D04748 E92F6370FF JMP -$8F9CD1 ; ($0040AA7C) System._HandleOnException
00D0474D 0100 ADD [EAX], EAX
00D0474F 0000 ADD [EAX], AL
00D04751 B400 MOV AH, 0

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Wed 28 Jan 2015 11:11

As we wrote earlier, we couldn't reproduce the problem, and we are unable to start investigating it without your sample demonstrating it. Make sure you are connecting to a Firebird server version not lower than 2.0, since in previous versions the TIBCQuery.DMLRefresh property doesn't work, according to our help, and to solve the problem, you should call TIBCQuery.Refresh after calling TIBCQuery.ApplyUpdates.

bzwirs
Posts: 40
Joined: Sat 10 Jul 2010 06:47

Re: TIBCQuery change in behaviour

Post by bzwirs » Sun 19 Apr 2015 08:09

Hi,

Didn't have time to pursue this earlier so reverted back to Version 5.4.12 where the problem doesn't occur. Have now tried again with your latest version (5.5) and the problem still exists for me.

The records I'm inserting are displayed in a grid from a temporary table. The user selects one or more of those records to be inserted in the database and clicks on a button to transfer the relevant data. The problem always occurs when more then one record is selected to be permanently saved.

Tried something different today which might help you understand my problem. I set the Debug property = True for the Query (SaleQry) that updates the key field with the generator value which I need to pass on to the other Query (MachSaleQry). As the program goes through adding several sales the debug windows that appear for each insertion are (Version 5.4.12):

EXECUTE
GET GENERATOR VALUE
INSERT
REFRESH

Now if I try the same with version 5.5 the GET GENERATOR VALUE appears for the first record only and gives me the Key Field value. The next records do not fire this event and I always seem to get a key field value of 1.

So it looks that my problem is that when inserting several records in a row, then the GET GENERATOR VALUE is not fired after the first insert and that is why I'm not getting the value needed since version 5.4.12.

Hope that you will be able to provide an answer to this new behaviour.

regards

Bill

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Mon 20 Apr 2015 08:42

Thank you for the information. We are investigating this behavior of IBDAC, and we will inform you about the results.

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Tue 21 Apr 2015 09:20

We have fixed this issue, the fix will be included in the next IBDAC build. If you want to get this fix before the next IBDAC version is released, please provide your license number and IDE version to viktorv*devart*com and we will send you a night build.

wesleybobato
Posts: 19
Joined: Thu 13 Feb 2014 12:28

Re: TIBCQuery change in behaviour

Post by wesleybobato » Tue 28 Apr 2015 19:16

Hello Support.

Please I need much, this correction
You can send me to [email protected]
I have the license and use Delphi XE First version.

Thank you.

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Wed 29 Apr 2015 08:16

You can find a IBDAC night build with a fix for this issue in the attachment to this letter.

ViktorV
Devart Team
Posts: 3168
Joined: Wed 30 Jul 2014 07:16

Re: TIBCQuery change in behaviour

Post by ViktorV » Tue 23 Jun 2015 09:36

The new IBDAC build with a fix for the issue is available for download now.

Post Reply