Error - Transaction of connection not set lazarus / 16-Databases ---------------------------------------------------------------------- valdir.marcos · 2018-09-01 02:34 Why IBConnection component looses its information about the default SQLTransaction component after first run? Important detail: I am using a second SQLTransaction for a SQLQuery. I have attached a small example: - Run the project; - Click Button1 to open Form2; - Click Button3 to run query. It works correctly; - Close Form2; - Click Button1 AGAIN to reopen Form2; - Click Button3 to run query. It gives error "Transaction of connection not set". EDatabaseError, SErrConnTransactionnSet, Transaction of connection not set ---------------------------------------------------------------------- mangakissa · 2018-09-01 07:01 Wrong approach. Use Datamodule. It looks like your sample is loosing the connection to Form1 after de caFree. Could be a bug, but I'm not sure. The datamodule has all it needs: the connection and query at one page. THe RTTI doesn't have to search where your component are put. ---------------------------------------------------------------------- valdir.marcos · 2018-09-01 09:45 Quote from: mangakissa on September 01, 2018, 09:01:34 amWrong approach. Use Datamodule.The real application uses datamodules and the problem is spread in hundreds of forms. QuoteIt looks like your sample is loosing the connection to Form1 after de caFree. Could be a bug, but I'm not sure.I am trying to confirm the problem before open a bug report. QuoteThe datamodule has all it needs: the connection and query at one page. THe RTTI doesn't have to search where your component are put.The real application uses datamodules to center what is general, like IBConnection; but SQLTransaction and SQLQuery belong to forms, just like in the old Delphi application that is being converted to Lazarus. ---------------------------------------------------------------------- valdir.marcos · 2018-09-01 10:13 Quote from: mangakissa on September 01, 2018, 09:01:34 amThe datamodule has all it needs: the connection and query at one page. THe RTTI doesn't have to search where your component are put.I really appreciate your help, but your solution is not consistent for this case. I can't have dozens of connections and hundreds of transactions and tables in only one data module. This is an old application in Delphi that is being migrated to Lazarus. There are hundreds of forms that contain between 1 and 3 tables. Having a data module for each form would be a huge waste of resources. In addition, there is only one connection for each database in the central data module. We only create an individual data module for each form when it needs many tables. Even in this case, the individual data module uses one of the connections that are in the central data module. ---------------------------------------------------------------------- mangakissa · 2018-09-01 20:02 The whole idea of using databases and GUI is seperating those things . Your form doesn't have to know how your query is connected. QuoteI can't have dozens of connections and hundreds of transactions and tables in only one data module.Your wrong. One datamodule is is global and runinng the connection. All other queries for each form can have his own datamodule. QuoteHaving a data module for each form would be a huge waste of resources.That's only when you open them all at once. Just create the datamodule when you open your form. QuoteThis is an old application in Delphi that is being migrated to Lazarus.So the developping of the program was wrong in the beginning. Quoten addition, there is only one connection for each database in the central data module. We only create an individual data module for each form when it needs many tables. Even in this case, the individual data module uses one of the connections that are in the central data module.First you tell all datacomponents ar on the form. Second you tell there's a an individual datamodule for each form. I'm confused write now. I'll give an solution bases on your example. I create a a large application over 60 forms and use 10 to 12 datamodules. I'm just open the datamodule I need for the form. All my connections to the database (except Tdatasource) doesn't know nothing about my databas. When I want a form rebuild, the connection the the database will be the same. Just connecting the form to the datamodule. My approach is: Form  <--> class object <--> datamodule ---------------------------------------------------------------------- sash · 2018-09-01 21:22 Try to explicitly set a Connection+Transaction for a Query in Form2.OnCreate. ---------------------------------------------------------------------- taazz · 2018-09-01 22:35 Quote from: valdir.marcos on September 01, 2018, 04:34:25 amWhy IBConnection component looses its information about the default SQLTransaction component after first run? Important detail: I am using a second SQLTransaction for a SQLQuery. I have attached a small example: - Run the project; - Click Button1 to open Form2; - Click Button3 to run query. It works correctly; - Close Form2; - Click Button1 AGAIN to reopen Form2; - Click Button3 to run query. It gives error "Transaction of connection not set". EDatabaseError, SErrConnTransactionnSet, Transaction of connection not set It is not a bug it is by design. When TSQLtransaction frees it self all controls that registered with its destruction mechanism are informed so they can react. TIBConnection at that point cleans up the internal field to avoid random memory access errors. Try to change the onclose action to caHide instead or even better do not use the form2's transaction as the default transaction of the database use it only as the transaction of the queries on form2. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 04:24 Quote from: mangakissa on September 01, 2018, 10:02:39 pmThe whole idea of using databases and GUI is seperating those things . Your form doesn't have to know how your query is connected.I agree. QuoteQuoteI can't have dozens of connections and hundreds of transactions and tables in only one data module.Your wrong. One datamodule is is global and runinng the connection. All other queries for each form can have his own datamodule.Which side do you put the transaction in? QuoteQuoteHaving a data module for each form would be a huge waste of resources.That's only when you open them all at once. Just create the datamodule when you open your form.Considering that most of the forms of the project deals with three or less tables. Instead of heaving more than one thousand files (forms) in the project, do you suggest to have more than two thousand files (forms and data modules)? QuoteQuoteThis is an old application in Delphi that is being migrated to Lazarus.So the developping of the program was wrong in the beginning.I don't agree. QuoteQuoten addition, there is only one connection for each database in the central data module. We only create an individual data module for each form when it needs many tables. Even in this case, the individual data module uses one of the connections that are in the central data module.First you tell all datacomponents ar on the form. Second you tell there's a an individual datamodule for each form. I'm confused write now.Not all situations are equal: - Central data module for connections without central transaction; - Individual transactions on forms or individual data modules; - Small quantity of tables, viewes or stored procedures WITHOUT individual data module; - Big quantity of tables, viewes or stored procedures WITH individual data module; ---------------------------------------------------------------------- taazz · 2018-09-02 04:48 Quote from: valdir.marcos on September 02, 2018, 06:24:43 amConsidering that most of the forms of the project deals with three or less tables. Instead of heaving more than one thousand files (forms) in the project, do you suggest to have more than two thousand files (forms and data modules)? No, by converting them to datamodules you will have the opportunity to use a single datamodule for multiple forms for example if the only difference between the 10 datamodules is the select query then create a single datamodule, pass that query as a parameter at the module's creation time and use it from the 10 different forms. If everything else fails then yes having 2000 files instead of 1000 forms is the recomended approach that will allow you to easily replace the forms when needed, eg when you target a different operating system or device (mobile, android, IOS etc). It all depends on the details though. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 05:01 Quote from: mangakissa on September 01, 2018, 10:02:39 pmI'll give an solution bases on your example. I create a a large application over 60 forms and use 10 to 12 datamodules.We do not have the same audience. I consider a small application when it has up to 500 files (forms, data modules and reports). A medium size up to 1,000 files. And a big one upwards. A similar idea may be considerated for their databases: a small database contains up to 500 objects (tables, views and stored procedures). A medium size up to 1,000 objects. And a big one upwards. Just as an example of my métier, a small ERP usually has around 1,000 files (forms, data modules and reports) and 1,000 objects (tables, views and stored procedures). QuoteI'm just open the datamodule I need for the form. All my connections to the database (except Tdatasource) doesn't know nothing about my databas. When I want a form rebuild, the connection the the database will be the same. Just connecting the form to the datamodule. My approach is: Form  <--> class object <--> datamoduleI agree with you for new long projects with high prepared team. I really like OPF (Object Persistence Framework) Coming back to reality, I have many constraints, including budget and deadline. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 05:02 Quote from: sash on September 01, 2018, 11:22:34 pmTry to explicitly set a Connection+Transaction for a Query in Form2.OnCreate.It's already done visually on Object Inspector. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 05:16 Quote from: taazz on September 02, 2018, 12:35:31 amQuote from: valdir.marcos on September 01, 2018, 04:34:25 amWhy IBConnection component looses its information about the default SQLTransaction component after first run?It is not a bug it is by design.Are you sure? QuoteWhen TSQLtransaction frees it self all controls that registered with its destruction mechanism are informed so they can react. TIBConnection at that point cleans up the internal field to avoid random memory access errors.I have destroyed and recreated the form, how is the information present on the first instance, but it just does not exist on next instances? It worked correctly on first run. Why it does not run correctly after destruction and recriation? QuoteTry to change the onclose action to caHide insteadWhat will hapen to memory if I don't destroy objects all day long? Quoteor even better do not use the form2's transaction as the default transaction of the databaseRevisit the sample project. Form2's transaction is not the default transaction of the connection. Quoteuse it only as the transaction of the queries on form2.It already is. ---------------------------------------------------------------------- taazz · 2018-09-02 05:36 Quote from: valdir.marcos on September 02, 2018, 07:16:36 amQuote from: taazz on September 02, 2018, 12:35:31 amQuote from: valdir.marcos on September 01, 2018, 04:34:25 amWhy IBConnection component looses its information about the default SQLTransaction component after first run?It is not a bug it is by design.Are you sure? 97% sure yes. Quote from: valdir.marcos on September 02, 2018, 07:16:36 amQuoteWhen TSQLtransaction frees it self all controls that registered with its destruction mechanism are informed so they can react. TIBConnection at that point cleans up the internal field to avoid random memory access errors.I have destroyed and recreated the form, how is the information present on the first instance, but it just does not exist on next instances? It worked correctly on first run. Why it does not run correctly after destruction and recriation? The first time it is executed, the settings where loaded from the lfm resources, and I assume some sort of delayed assignment is setup(I do not remember the exact details how this works you need to verify it). The Transaction's onDestroy even has not been executed yet, after form2 is created the delayed assignment is executed and the link is now complete. When the the Teansaction is destroyed as a result of the caFree action, the connection gets informed and reacting on the event it destroys any and all links to a dead object, subsequent call to TForm2.Create do not have any info to link the two components again. The mechanism is used primarily on the IDE designer when you delete a linked transaction all objects that are linked to it are informed and instead of a SigSegV error they clean up their internal fields. For that I'm 100% sure. Quote from: valdir.marcos on September 02, 2018, 07:16:36 am QuoteTry to change the onclose action to caHide insteadWhat will hapen to memory if I don't destroy objects all day long? I can not answer that, I can only say that if care is taken to close the queries in the onclose event then the used memory should not change that much except if there are memory leaks somewhere. Quote from: valdir.marcos on September 02, 2018, 07:16:36 am Quoteor even better do not use the form2's transaction as the default transaction of the databaseRevisit the sample project. Form2's transaction is not the default transaction of the connection. Yes it is, see attached image. Quote from: valdir.marcos on September 02, 2018, 07:16:36 amQuoteuse it only as the transaction of the queries on form2.It already is. then why you need it to be the default transaction of the connection? ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 05:52 Quote from: taazz on September 02, 2018, 06:48:54 amQuote from: valdir.marcos on September 02, 2018, 06:24:43 amConsidering that most of the forms of the project deals with three or less tables. Instead of heaving more than one thousand files (forms) in the project, do you suggest to have more than two thousand files (forms and data modules)?No, by converting them to datamodules you will have the opportunity to use a single datamodule for multiple forms for example if the only difference between the 10 datamodules is the select query then create a single datamodule, pass that query as a parameter at the module's creation time and use it from the 10 different forms.This is not compliant to the KISS principle. Here in Brazil, your suggestion would be considered "Programação Orientada a Gambiarras (POG)", something similiar to "Workaround- Oriented Programming (WOP).  QuoteIf everything else fails then yes having 2000 files instead of 1000 forms is the recomended approach that will allow you to easily replace the forms when needed, eg when you target a different operating system or device (mobile, android, IOS etc). It all depends on the details though.This small ERP was created using Borland Delphi 2 (1996), more than 20 years ago. And upgraded up to Borland Delphi 7 (2002), more than 15 years ago. Since then, this application is only maintained using Delphi 7. Now it is being migrated to Lazarus. It will not be rewritten from scratch, it will only be migrated in the simplest way for the shortest possible time and at the lowest possible cost. After that, it will be rewritten for internet (most likely PHP) and mobile (most likely Kotlin and Swift) and it will die for the Desktop version within a few years. It's sad, but new programmmers don't learn Pascal in college anymore. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 05:59 Quote from: taazz on September 02, 2018, 07:36:06 amQuote from: valdir.marcos on September 02, 2018, 07:16:36 amQuote from: taazz on September 02, 2018, 12:35:31 amQuote from: valdir.marcos on September 01, 2018, 04:34:25 amWhy IBConnection component looses its information about the default SQLTransaction component after first run?It is not a bug it is by design.Are you sure? 97% sure yes. Quote from: valdir.marcos on September 02, 2018, 07:16:36 amQuoteWhen TSQLtransaction frees it self all controls that registered with its destruction mechanism are informed so they can react. TIBConnection at that point cleans up the internal field to avoid random memory access errors.I have destroyed and recreated the form, how is the information present on the first instance, but it just does not exist on next instances? It worked correctly on first run. Why it does not run correctly after destruction and recriation? The first time it is executed, the settings where loaded from the lfm resources, and I assume some sort of delayed assignment is setup(I do not remember the exact details how this works you need to verify it). The Transaction's onDestroy even has not been executed yet, after form2 is created the delayed assignment is executed and the link is now complete. When the the Teansaction is destroyed as a result of the caFree action, the connection gets informed and reacting on the event it destroys any and all links to a dead object, subsequent call to TForm2.Create do not have any info to link the two components again. The mechanism is used primarily on the IDE designer when you delete a linked transaction all objects that are linked to it are informed and instead of a SigSegV error they clean up their internal fields. For that I'm 100% sure.This is very bad news. ---------------------------------------------------------------------- taazz · 2018-09-02 06:06 Quote from: valdir.marcos on September 02, 2018, 07:52:24 amQuote from: taazz on September 02, 2018, 06:48:54 amQuote from: valdir.marcos on September 02, 2018, 06:24:43 amConsidering that most of the forms of the project deals with three or less tables. Instead of heaving more than one thousand files (forms) in the project, do you suggest to have more than two thousand files (forms and data modules)?No, by converting them to datamodules you will have the opportunity to use a single datamodule for multiple forms for example if the only difference between the 10 datamodules is the select query then create a single datamodule, pass that query as a parameter at the module's creation time and use it from the 10 different forms.This is not compliant to the KISS principle. Here in Brazil, your suggestion would be considered "Programação Orientada a Gambiarras (POG)", something similiar to "Workaround- Oriented Programming (WOP).  I guess its a point of view. The described process is a good example of a top down design process. There is nothing "workaround" about it. Quote from: valdir.marcos on September 02, 2018, 07:52:24 amNow it is being migrated to Lazarus. It will not be rewritten from scratch, it will only be migrated in the simplest way for the shortest possible time and at the lowest possible cost. then its a waste of time and effort to port it to lazarus. stop and start working on the web version the faster it will finish the faster the old app will be decommissioned. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 06:15 Quote from: taazz on September 02, 2018, 07:36:06 amQuoteor even better do not use the form2's transaction as the default transaction of the databaseQuote from: valdir.marcos on September 02, 2018, 07:16:36 amRevisit the sample project. Form2's transaction is not the default transaction of the connection.Yes it is, see attached image.The image you attached is showing Form1, IBConnection1, SQLTransaction1, which is the default transaction of the connection. But we are talking about Form2, no IBConnection, SQLTransaction2, which is the individual transaction for SQLQuery2. See attached image. QuoteQuote from: valdir.marcos on September 02, 2018, 07:16:36 amQuoteuse it only as the transaction of the queries on form2.It already is.then why you need it to be the default transaction of the connection?The default transaction (SQLTransaction1 on Form1) is necessary for IBConnection1 to do internal jobs, such as build automatically (ParseSQL) Insert, Update and Delete commands for a provided Select. ---------------------------------------------------------------------- taazz · 2018-09-02 06:21 Quote from: valdir.marcos on September 02, 2018, 08:15:31 amQuote from: taazz on September 02, 2018, 07:36:06 amQuoteor even better do not use the form2's transaction as the default transaction of the databaseQuote from: valdir.marcos on September 02, 2018, 07:16:36 amRevisit the sample project. Form2's transaction is not the default transaction of the connection.Yes it is, see attached image.The image you attached is showing Form1, IBConnection1, SQLTransaction1, which is the default transaction of the connection. But we are talking about Form2, no IBConnection, SQLTransaction2, which is the individual transaction for SQLQuery2. See attached image. no it does not. look at the object inspector on the left. The focused transaction property says otherwise. PS   you might have to set the transaction's connection property instead though. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 06:37 Quote from: taazz on September 02, 2018, 08:06:24 amQuote from: valdir.marcos on September 02, 2018, 07:52:24 amNow it is being migrated to Lazarus. It will not be rewritten from scratch, it will only be migrated in the simplest way for the shortest possible time and at the lowest possible cost.Quotethen its a waste of time and effort to port it to lazarus.No, it's not. It is faster and less expensive. It's a RAD project. Quotestop and start working on the web version the faster it will finish the faster the old app will be decommissioned.The web and mobile project would cost ten times more and it would be developed three times slower than the desktop project. I know that by other clients that are doing it... Build a small ERP is not an easy task for a desktop application, but it's a real challenge for web and mobile applications. Legal system (sell and buy products and services, pay taxes, etc) in Brazil is not for beginners. ---------------------------------------------------------------------- valdir.marcos · 2018-09-02 07:09 Quote from: taazz on September 02, 2018, 08:21:16 amQuote from: valdir.marcos on September 02, 2018, 08:15:31 amQuote from: taazz on September 02, 2018, 07:36:06 amQuoteor even better do not use the form2's transaction as the default transaction of the databaseQuote from: valdir.marcos on September 02, 2018, 07:16:36 amRevisit the sample project. Form2's transaction is not the default transaction of the connection.Yes it is, see attached image.The image you attached is showing Form1, IBConnection1, SQLTransaction1, which is the default transaction of the connection. But we are talking about Form2, no IBConnection, SQLTransaction2, which is the individual transaction for SQLQuery2. See attached image.no it does not. look at the object inspector on the left. The focused transaction property says otherwise. PS   you might have to set the transaction's connection property instead though.You are right. And this matter seems to be solved. Thanks you so much. But now, it seems we have a real bug. Detail data module sees master data module, but not the contrary in the actual application, exactly as the sample project I have provided. How that information was transported from detail data module (Form2) to master data module (Form1) during design time? I will create another sample project from scratch to figure it out. ---------------------------------------------------------------------- taazz · 2018-09-02 07:20 Quote from: valdir.marcos on September 02, 2018, 09:09:16 amBut now, it seems we have a real bug. Detail data module sees master data module, but not the contrary in the actual application, exactly as the sample project I have provided. How that information was transported from detail data module (Form2) to master data module (Form1) during design time? Which is the detail and which is the master? If I assume that form1 is the master and form2 the detail then the detail needs to see the master and connect the sqlquery to the IBConnection, that's the only link required for the query to be able to talk to the database and consequently to the master data module. Quote from: valdir.marcos on September 02, 2018, 09:09:16 amI will create another sample project from scratch to figure it out. That would be helpful in case I misunderstood the description above. ---------------------------------------------------------------------- mangakissa · 2018-09-02 09:41 Back to the original problem. I put this line of code in your sample: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm2.FormShow(Sender: TObject);begin  Form2.SQLQuery2.DataBase := Form1.IBConnection1 ;  Form2.SQLQuery2.Transaction := Form2.SQLTransaction2;  Form2.SQLTransaction2.DataBase := Form1.IBConnection1;end; It results with the same error (no connection or transaction). That's strange, because the link to the database and transaction is linked @runtime. I even put an showmessage on OnShow to check if Form.IBConnection1 is available. At this point I don't now where the problem exists. With a datamodule it works fine. QuoteApplication is build in D2 originallyNow I understand why all datacomponents are put on form. But when converting to D7 it was the best thing to build the application on datamodule ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 12:56 Quote from: taazz on September 02, 2018, 09:20:23 amQuote from: valdir.marcos on September 02, 2018, 09:09:16 amBut now, it seems we have a real bug. Detail data module sees master data module, but not the contrary in the actual application, exactly as the sample project I have provided. How that information was transported from detail data module (Form2) to master data module (Form1) during design time?Which is the detail and which is the master? If I assume that form1 is the master and form2 the detailCorrect. Quotethen the detail needs to see the master and connect the sqlquery to the IBConnection, that's the only link required for the query to be able to talk to the database and consequently to the master data module. I know that, but in this case, each form needs its own transaction. I will relate below what I have discovered so far. ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 13:01 Quote from: mangakissa on September 02, 2018, 11:41:37 amBack to the original problem. I put this line of code in your sample: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TForm2.FormShow(Sender: TObject);begin  Form2.SQLQuery2.DataBase := Form1.IBConnection1 ;  Form2.SQLQuery2.Transaction := Form2.SQLTransaction2;  Form2.SQLTransaction2.DataBase := Form1.IBConnection1;end;It results with the same error (no connection or transaction). That's strange, because the link to the database and transaction is linked @runtime. I even put an showmessage on OnShow to check if Form.IBConnection1 is available. At this point I don't now where the problem exists.I can confirm and I believe this is a bug. Otherwise, forms would have to be forbidden to have SQLdb components. QuoteWith a datamodule it works fine. ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 13:06 Quote from: mangakissa on September 02, 2018, 11:41:37 amApplication is build in D2 originally. Now I understand why all datacomponents are put on form. But when converting to D7 it was the best thing to build the application on datamoduleI respect you opinion, but I believe that data modules should not be a panacea, like anything else. ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 13:17 First case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Set SQLTransaction2.Database as Form1.IBConection1; 6. Check Form1.IBConection1.Transaction information. Why Form2.SQLTransaction2 has became the default transaction of Form1.IBConection1 if Form2 is not even in Form1's uses sections? ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 13:32 Second case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Create Form3; 6. Put a SQLTransaction3 on Form3; 7. Check Form1.IBConection1.Transaction information. Why Form1.IBConection1 permits see Form2.SQLTransaction2 and Form3.SQLTransaction3 if Form2 and Form3 are not even in Form1's uses sections? Isn't this case a bug in design time information? ---------------------------------------------------------------------- taazz · 2018-09-03 13:34 Quote from: valdir.marcos on September 03, 2018, 03:17:05 pmFirst case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Set SQLTransaction2.Database as Form1.IBConection1; 6. Check Form1.IBConection1.Transaction information. Why Form2.SQLTransaction2 has became the default transaction of Form1.IBConection1 if Form2 is not even in Form1's uses sections? Because SQLTransaction2 (which is the control that sets the Transaction property on the IBConnection) has no information of form1's use list nor form2's. You can stop that by setting the IConnection transaction property to something else before setting the SQLTransaction.Database property. ---------------------------------------------------------------------- taazz · 2018-09-03 13:38 Quote from: valdir.marcos on September 03, 2018, 03:32:46 pmSecond case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Create Form3; 6. Put a SQLTransaction3 on Form3; 7. Check Form1.IBConection1.Transaction information. Why Form1.IBConection1 permits see Form2.SQLTransaction2 and Form3.SQLTransaction3 if Form2 and Form3 are not even in Form1's uses sections? Isn't this case a bug in design time information? That's a feature of the IDE Designer, once you link a property to a control on an other form it will automatically append that form to the uses clause. ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 13:43 Quote from: taazz on September 03, 2018, 03:34:52 pmQuote from: valdir.marcos on September 03, 2018, 03:17:05 pmFirst case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Set SQLTransaction2.Database as Form1.IBConection1; 6. Check Form1.IBConection1.Transaction information. Why Form2.SQLTransaction2 has became the default transaction of Form1.IBConection1 if Form2 is not even in Form1's uses sections?Because SQLTransaction2 (which is the control that sets the Transaction property on the IBConnection) has no information of form1's use list nor form2's. You can stop that by setting the IConnection transaction property to something else before setting the SQLTransaction.Database property.Isn't a bug when design time allows something that run time won't? ---------------------------------------------------------------------- taazz · 2018-09-03 13:44 Quote from: valdir.marcos on September 03, 2018, 03:43:10 pmQuote from: taazz on September 03, 2018, 03:34:52 pmQuote from: valdir.marcos on September 03, 2018, 03:17:05 pmFirst case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Set SQLTransaction2.Database as Form1.IBConection1; 6. Check Form1.IBConection1.Transaction information. Why Form2.SQLTransaction2 has became the default transaction of Form1.IBConection1 if Form2 is not even in Form1's uses sections?Because SQLTransaction2 (which is the control that sets the Transaction property on the IBConnection) has no information of form1's use list nor form2's. You can stop that by setting the IConnection transaction property to something else before setting the SQLTransaction.Database property.Isn't a bug when design time allows something that run time won't? NO! its a helping hand it makes things easier to work with. EDIT:    Just a comment to get it out of my system. The uses clause is compiler instructions not run time behavior. ---------------------------------------------------------------------- valdir.marcos · 2018-09-03 14:04 Quote from: taazz on September 03, 2018, 03:38:16 pmQuote from: valdir.marcos on September 03, 2018, 03:32:46 pmSecond case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Create Form3; 6. Put a SQLTransaction3 on Form3; 7. Check Form1.IBConection1.Transaction information. Why Form1.IBConection1 permits see Form2.SQLTransaction2 and Form3.SQLTransaction3 if Form2 and Form3 are not even in Form1's uses sections? Isn't this case a bug in design time information? That's a feature of the IDE Designer, once you link a property to a control on an other form it will automatically append that form to the uses clause.Even if I have hundreds of forms should I see hundreds of undesired information? ---------------------------------------------------------------------- taazz · 2018-09-03 14:31 Quote from: valdir.marcos on September 03, 2018, 04:04:38 pmQuote from: taazz on September 03, 2018, 03:38:16 pmQuote from: valdir.marcos on September 03, 2018, 03:32:46 pmSecond case: 1. Create a new project; 2. Put a IBConection1 on Form1; 3. Create Form2; 4. Put a SQLTransaction2 on Form2; 5. Create Form3; 6. Put a SQLTransaction3 on Form3; 7. Check Form1.IBConection1.Transaction information. Why Form1.IBConection1 permits see Form2.SQLTransaction2 and Form3.SQLTransaction3 if Form2 and Form3 are not even in Form1's uses sections? Isn't this case a bug in design time information? That's a feature of the IDE Designer, once you link a property to a control on an other form it will automatically append that form to the uses clause.Even if I have hundreds of forms should I see hundreds of undesired information? Well now we venture in to the specification realm, which has no technical weight. Here is a fact and my opinion. Fact: You can only select from forms/datamodules loaded in ide, not all of them are usually loaded at the same time but if they are, (Opinion time) then yes you should be able to use anything from anywhere on your project and have the IDE sort out the uses clause for you. ---------------------------------------------------------------------- valdir.marcos · 2018-09-04 18:52 It seems that I have discovered what happens, but I am not sure how to reproduce. I visually configure some SQLTransaction and SQLQuery in a form. When all is right, I save it and close Lazarus. I open the LFM file in Notepad++ and the information in SQLQuery.Transaction has been saved correctly. I open the project in Lazarus again and the information in SQLQuery.Transaction is loaded wrongly. It even seems random. It might be related to many open forms simultaneously when saving and loading. If I recompile that unit, then when I run the application, errors come up and that do not make sense since it worked correctly before. I reconfigure the SQLQuery.Transaction of that form and the application returns to work. ---------------------------------------------------------------------- taazz · 2018-09-05 07:03 Quote from: valdir.marcos on September 04, 2018, 08:52:18 pmIt seems that I have discovered what happens, but I am not sure how to reproduce. I visually configure some SQLTransaction and SQLQuery in a form. When all is right, I save it and close Lazarus. I open the LFM file in Notepad++ and the information in SQLQuery.Transaction has been saved correctly. I open the project in Lazarus again and the information in SQLQuery.Transaction is loaded wrongly. It even seems random. It might be related to many open forms simultaneously when saving and loading. That looks like a huge bug. how repeatable is this? does it hapen every time you load the form or its a bit random? Quote from: valdir.marcos on September 04, 2018, 08:52:18 pmIf I recompile that unit, then when I run the application, errors come up and that do not make sense since it worked correctly before. I reconfigure the SQLQuery.Transaction of that form and the application returns to work. I see which means that the problem is on the designer not the streaming mechanism it self. ---------------------------------------------------------------------- valdir.marcos · 2018-09-05 11:02 Quote from: taazz on September 05, 2018, 09:03:37 amQuote from: valdir.marcos on September 04, 2018, 08:52:18 pmIt seems that I have discovered what happens, but I am not sure how to reproduce. I visually configure some SQLTransaction and SQLQuery in a form. When all is right, I save it and close Lazarus. I open the LFM file in Notepad++ and the information in SQLQuery.Transaction has been saved correctly. I open the project in Lazarus again and the information in SQLQuery.Transaction is loaded wrongly. It even seems random. It might be related to many open forms simultaneously when saving and loading.That looks like a huge bug. how repeatable is this?As more forms are being added to the project, the bug happens on a daily basis. Quotedoes it hapen every time you load the form or its a bit random?It seems to happen every time when I load the bug forms, but I could not reproduce it on a small sample project so far. QuoteQuote from: valdir.marcos on September 04, 2018, 08:52:18 pmIf I recompile that unit, then when I run the application, errors come up and that do not make sense since it worked correctly before. I reconfigure the SQLQuery.Transaction of that form and the application returns to work.I see which means that the problem is on the designer not the streaming mechanism it self.I also believe you are right, but I still need to create a small sample project to show the bug happening. ---------------------------------------------------------------------- valdir.marcos · 2018-09-06 05:35 @mangakissa and @taazz Bug on Lazarus 1.8.4 and FPC 3.0.4 and Firebird 3.0.3: Information about Form.SQLQuery.Transaction is saved correctly on LFM file, but is loaded wrongly during design time. Then, ApplyUpdate(0) gives random errors. I have a small project (1 data module and 3 forms) build from scratch that shows the problem. I can send it privately if one of you have some time to debug it and discard it, but it can't become public because of copyright. We also can't discuss it publicly. We can only talk publicly and generically about IBConnection, SQLTransaction and SQLQuery. ---------------------------------------------------------------------- taazz · 2018-09-06 06:15 Quote from: valdir.marcos on September 06, 2018, 07:35:23 am@mangakissa and @taazz Bug on Lazarus 1.8.4 and FPC 3.0.4 and Firebird 3.0.3: Information about Form.SQLQuery.Transaction is saved correctly on LFM file, but is loaded wrongly during design time. Then, ApplyUpdate(0) gives random errors. I have a small project (1 data module and 3 forms) build from scratch that shows the problem. I can send it privately if one of you have some time to debug it and discard it, but it can't become public because of copyright. We also can't discuss it publicly. We can only talk publicly and generically about IBConnection, SQLTransaction and SQLQuery. sure, why not, I'll take a closer look at the weekend, I'll pm you an active email address. ---------------------------------------------------------------------- valdir.marcos · 2018-09-06 16:00 Quote from: taazz on September 06, 2018, 08:15:31 amQuote from: valdir.marcos on September 06, 2018, 07:35:23 am@mangakissa and @taazz Bug on Lazarus 1.8.4 and FPC 3.0.4 and Firebird 3.0.3: Information about Form.SQLQuery.Transaction is saved correctly on LFM file, but is loaded wrongly during design time. Then, ApplyUpdate(0) gives random errors. I have a small project (1 data module and 3 forms) build from scratch that shows the problem. I can send it privately if one of you have some time to debug it and discard it, but it can't become public because of copyright. We also can't discuss it publicly. We can only talk publicly and generically about IBConnection, SQLTransaction and SQLQuery.sure, why not, I'll take a closer look at the weekend, I'll pm you an active email address.I have just sent you an e-mail. Thanks. ---------------------------------------------------------------------- LacaK · 2018-12-07 06:39 To comment bug report https://bugs.freepascal.org/view.php?id=34648: If you can select in one DataModule transaction from another DataModule, which is not in USES list then I think, that it is bug. But this must confirm and fix someone of Lazarus developer. I am not so familiar with streaming system. ---------------------------------------------------------------------- valdir.marcos · 2018-12-13 19:15 Quote from: LacaK on December 07, 2018, 07:39:49 amTo comment bug report https://bugs.freepascal.org/view.php?id=34648: If you can select in one DataModule transaction from another DataModule, which is not in USES list then I think, that it is bug. But this must confirm and fix someone of Lazarus developer. I am not so familiar with streaming system.I have opened an apart ticket for this issue: 0034686: Database Settings -> confunsing information and possibility of setting wrong values https://bugs.freepascal.org/view.php?id=34686 Thanks.