[DUG] How to progress SQL

russell russell at belding.co.nz
Sun Jun 28 20:19:15 NZST 2015 

Hi Wallace

The are many ways to manage this example and the process you describe
depends on the transactions you use in mainForm and childForm.
If each form (datasets in the form)  is using commonTransaction I'd guess
childForm would see the new record. If mainForm uses mainTransacation and
childForm uses childTransaction then 
MainForm should have mainTransaction commit or commitRetaining before
childForm using childTransaction would see the new record.

I am answering this as if I were using Firebird. I am not sue o the details
of mySql.

Russell

-----Original Message-----
From: delphi-bounces at listserver.123.net.nz
[mailto:delphi-bounces at listserver.123.net.nz] On Behalf Of Marshland
Engineering
Sent: Sunday, 28 June 2015 5:52 p.m.
To: delphi at listserver.123.net.nz
Subject: [DUG] How to progress SQL

I have used MYSQL as it is Delphi/PHP etc friendly, however, with Devart
components, I'm really pulling my hair out.

Maybe I'm not using the bits as Devart expected, but I'm using standard
Delphi language.

I found a new issue. 

In my main form I have an option to add a new record, 

if MessageDlg('Add member ?',mtConfirmation, [mbYes, mbNo], 0)= mrYes then
begin
   dm.tblMaster.Append;  
   fMembers.ShowModal; 

In the child form, which is called from a few other options, I have a record
refresh to ensure I have the latest data in a multiuser environment, 

procedure TfMembers.FormShow(Sender: TObject); begin
   dm.tblMaster.RefreshRecord;
   dm.tblClubMemMast.RefreshRecord;
   dm.tblMaster.Edit;

However, my newly appended record is now gone and I'm positioned on another
valid record.

Do I persist with Devart and learn all the oddities or try something else ?

Any suggestions please.

Thanks Wallace


 


--
Thanking you
Wallace Weideman
Marshland Engineering
704 Marshland Road
Styx
Christchurch
03 3237449
www.marshland.co.nz

On 26/06/2015 at 12:00, delphi-request at listserver.123.net.nz wrote:
>Send Delphi mailing list submissions to
>	delphi at listserver.123.net.nz
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://listserver.123.net.nz/mailman/listinfo/delphi
>or, via email, send a message with subject or body 'help' to
>	delphi-request at listserver.123.net.nz
>
>You can reach the person managing the list at
>	delphi-owner at listserver.123.net.nz
>
>When replying, please edit your Subject line so it is more specific 
>than "Re: Contents of Delphi digest..."
>
>
>Today's Topics:
>
>   1. RE Relationship or not (Marshland Engineering)
>   2. Re: RE Relationship or not (Jolyon Smith)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 25 Jun 2015 22:41:04 +1200
>From: "Marshland Engineering" <marshland at marshland.co.nz>
>Subject: [DUG] RE Relationship or not
>To: delphi at listserver.123.net.nz
>Message-ID: <534439939417954933 at marshland.co.nz>
>Content-Type: text/plain; charset=UTF-8
>
>Hi chaps and update. Barry, Eric and Alistair all came to the rescue 
>and I learned something from each one. Thanks very much.
>
>I'm using Devart for Mysql access. 
>
>So what I have learned is, that, if you have a Master Detail 
>relationship and you do a post with the Master table, the Detail table 
>changes from edit to browse mode all by itself. !!!!
>
>Along the same lines if you have a Master Detail relationship and look 
>to see if there is a Detail entry for a Master record and there isn't 
>one, when you put the master into edit mode, it automatically creates 
>one for you (or a virtual one) in the detail form so any conditional 
>statement with the Detail table now returns true.
>
>So with Devarts components- things happen behind the scenes which can be
hard
>to find.   
>
>Thanks Wallace
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 26 Jun 2015 07:59:33 +1200
>From: Jolyon Smith <jsmith at deltics.co.nz>
>Subject: Re: [DUG] RE Relationship or not
>To: NZ Borland Developers Group - Delphi List
>	<delphi at listserver.123.net.nz>
>Message-ID:
>	<CALXexOqv-AVcM+vDTT4A_bZT51AhWvhBhEbn81PXNpzE8MC+Jw at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>"things happen behind the scenes which can be hard to find"
>
>In my experience this holds true for *any* component based, 
>drag-and-drop development approach.  DevArt components are no different 
>in this respect than any other framework.
>
>That, and the fact that program behaviours are driven, sometimes subtly 
>and sometimes significantly, by minor variations in component 
>properties that are immeasurably more difficult to discover than 
>changes resulting from difference in actual code, is why I avoid using 
>such frameworks for application development like the proverbial.
>
>You can create an app that works (or seems to) very quickly.  But when 
>problems arise or you need to change or extend the behaviour or 
>implement something which doesn't fit with the way that the components 
>you are using expect or intend you to, the effort involved (and 
>unintended side effects
>arising) then can be disastrously disproportionate.
>
>imho
>ymmv
>
>On 25 June 2015 at 22:41, Marshland Engineering 
><marshland at marshland.co.nz>
>wrote:
>
>> Hi chaps and update. Barry, Eric and Alistair all came to the rescue 
>> and I learned something from each one. Thanks very much.
>>
>> I'm using Devart for Mysql access.
>>
>> So what I have learned is, that, if you have a Master Detail 
>> relationship and you do a post with the Master table, the Detail 
>> table changes from edit to browse mode all by itself. !!!!
>>
>> Along the same lines if you have a Master Detail relationship and 
>> look to see if there is a Detail entry for a Master record and there 
>> isn't one, when you put the master into edit mode, it automatically 
>> creates one for you (or a virtual one) in the detail form so any 
>> conditional statement with the Detail table now returns true.
>>
>> So with Devarts components- things happen behind the scenes which can 
>> be hard to find.
>>
>> Thanks Wallace
>>
>> _______________________________________________
>> NZ Borland Developers Group - Delphi mailing list
>> Post: delphi at listserver.123.net.nz
>> Admin: http://delphi.org.nz/mailman/listinfo/delphi
>> Unsubscribe: send an email to delphi-request at listserver.123.net.nz 
>> with
>> Subject: unsubscribe
>>
>-------------- next part -------------- An HTML attachment was 
>scrubbed...
>URL:
http://listserver.123.net.nz/pipermail/delphi/attachments/20150626/4356b1f0/
attachment-0001.html
>
>------------------------------
>
>_______________________________________________
>Delphi mailing list
>Delphi at listserver.123.net.nz
>http://listserver.123.net.nz/mailman/listinfo/delphi
>
>End of Delphi Digest, Vol 140, Issue 12
>***************************************

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with
Subject: unsubscribe

More information about the Delphi mailing list