[Lazarus] Handling Firebird connection
Hi all, I have the following code that I use to connect to a Firebird database, which works fine, however, if the Firebird server becomes unavailable, fIBConnection.Connected always returns true. What's the best way of checking to make sure that the Firebird server is still available before I attempt to connect to the database? Thanks in advance Richard fOnline := True; try if fIBConnection.Connected then Exit; with fIBConnection do begin HostName := 'hostname'; DatabaseName := 'location'; UserName := 'username'; Password := 'password'; end; end; fIBConnection.Transaction := fSQLTransaction; with fSQLQuery do begin DataBase := fIBConnection; Transaction := fSQLTransaction; end; //Finally switch on connection fSQLTransaction.DataBase := fIBConnection; fIBConnection.Connected := True; except fOnline := False; end; -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Handling Firebird connection
Le 25/08/2014 09:32, Richard Mace a écrit : Hi all, I have the following code that I use to connect to a Firebird database, which works fine, however, if the Firebird server becomes unavailable, fIBConnection.Connected always returns true. What's the best way of checking to make sure that the Firebird server is still available before I attempt to connect to the database? AFAIK the TIbConnection is based upon TSQLConnection itself based upon the TDatabase component. In all this chain the Connected property is defined in the latest component, the TDatabase. And the Connected property has a read function wich sends a boolean variable content (FConnected variable). That's why once the first connection has been established with the Firebird server (whether is succeeds or not), the connection status is kept thru all component life until next disconnect or re-connect operation takes place. To solve the situation when the link to the databse server is broken I rely on the transaction mechanism. In fact I always control the transaction state allowing any query to be executed, as the Firebird server requires that any database access has to be done under the control of a transaction. This means thar when the MyTrans.StartTransaction fails I know (most of the times) that the link to the FB server is broken (omitting programmatic errors which can be controlled or checkced in another way). This does not protect your code from a connection exception between two consecutive database access (two consecutive calls to the fbclient library anyway). When I need a fine tuned control over a database access, after a initial MyDB.Connected := True, I always use the same sequence: try MyDatabase.Connedted := True; except on ...(exception process) do ... connection fault end [...] prepare data for the database try MyTransaction;StartTransaction try do whatever has to be done with the database finally MyTransaction.Commit end except do whatever needed when the exception rises: check whether its is an ordinary exception or a server link fault if MyTransaction.InTransaction then MyTransaction.RollBack; end; This sequence does not protect against the server disconnection between two consecutive database calls. I easily can imagine that the same process occurs with any other database server hosted in a remote machine. Even when the database server is hosted in the same machine of the applicaton, TCP/IP communication applies. Antonio. --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Handling Firebird connection
Antonia, Many thanks for your reply. I'll re-code my app and do some more testing. Richard On 25 August 2014 09:19, SPRL AFOR afors...@gmail.com wrote: Le 25/08/2014 09:32, Richard Mace a écrit : Hi all, I have the following code that I use to connect to a Firebird database, which works fine, however, if the Firebird server becomes unavailable, fIBConnection.Connected always returns true. What's the best way of checking to make sure that the Firebird server is still available before I attempt to connect to the database? AFAIK the TIbConnection is based upon TSQLConnection itself based upon the TDatabase component. In all this chain the Connected property is defined in the latest component, the TDatabase. And the Connected property has a read function wich sends a boolean variable content (FConnected variable). That's why once the first connection has been established with the Firebird server (whether is succeeds or not), the connection status is kept thru all component life until next disconnect or re-connect operation takes place. To solve the situation when the link to the databse server is broken I rely on the transaction mechanism. In fact I always control the transaction state allowing any query to be executed, as the Firebird server requires that any database access has to be done under the control of a transaction. This means thar when the MyTrans.StartTransaction fails I know (most of the times) that the link to the FB server is broken (omitting programmatic errors which can be controlled or checkced in another way). This does not protect your code from a connection exception between two consecutive database access (two consecutive calls to the fbclient library anyway). When I need a fine tuned control over a database access, after a initial MyDB.Connected := True, I always use the same sequence: try MyDatabase.Connedted := True; except on ...(exception process) do ... connection fault end [...] prepare data for the database try MyTransaction;StartTransaction try do whatever has to be done with the database finally MyTransaction.Commit end except do whatever needed when the exception rises: check whether its is an ordinary exception or a server link fault if MyTransaction.InTransaction then MyTransaction.RollBack; end; This sequence does not protect against the server disconnection between two consecutive database calls. I easily can imagine that the same process occurs with any other database server hosted in a remote machine. Even when the database server is hosted in the same machine of the applicaton, TCP/IP communication applies. Antonio. -- http://www.avast.com/ Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection Antivirus avast! http://www.avast.com/ est active. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Handling Firebird connection
Hi Antonia, This sequence does not protect against the server disconnection between two consecutive database calls. Would you mind giving me an example of this? Thanks Richard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 24/08/14 16:44, Joost van der Sluis wrote:
On 07/21/2014 10:11 PM, C Western wrote:
Managed to create a small test program:
program tproj;
uses sysutils;
procedure a(const s: string);
var
a: string;
r: array [0..10] of Double;
begin
a := s+s+s;
r[8] := StrToFloat(a);
WriteLn(a, ' ', r[8])
end;
begin
a('6'); -Set break point here, and hit step into here twice
end.
First step into ends on begin in procedure, second on final end.
Seems to be related to size of stack frame - if I didn't have the
array in, it works as expected. I compiled it with all stack checks on.
I know this stuff can be difficult - I have certainly seen some odd
things with Delphi and gdb. My hope is we can resolve some of these
things as we now have control over all parts of the system.
Solving this particular problem was easy, but debugging your
test-application opened a whole new can of worms.
I've re-written the step-into-line code completely. It's not fool-proof,
but at least it works stepping into a procedure one level deep. (That
means: if the procedure being called has debug-info.) If it does not
have debug-info but another procedure with debug info is called
further-on, it will probably work.
The problem lies in functions that do not set the stack-frame. Among
those are the compiler-procedures. If two of those are called after each
other, the debugger can loose track...
So, please test. I'm convinced that a solution that always works and is
also reasonable fast is impossible. (gdb also makes comparable mistakes)
Oh, and I added re-direction of the console in- and output to the
console-debug screen.
Thanks for looking at this - I will try it out. Two things strike me:
1. How about a slow step option?
2. Could the compiler add more information to make this easier? Or is it
simply a matter of compiling everything with a stack frame?
Colin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] font.name=default
nice. I´ll try it. (my recursive procedure worked well, not a big deal!). I had some difficulty to find informations about controls, components ... if you about them you can find the reference ... but it does not help much! ... any hint? P. Em 24.08.2014 21:48, Hans-Peter Diettrich escreveu: Philippe schrieb: just for information ... I tried to use your suggestion ... it works ... but ... I am using TGroupBox in TGroupBox in TGroupBox ... your example just loops on the top level controls of the form ... needing to use recursive function to go through contained group boxes ... what I´ll do later. Then use Components[] instead of Controls[]. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus [1] Links: -- [1] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Mon, Aug 25, 2014 at 6:26 AM, C Western l...@c-m-w.me.uk wrote: 1. How about a slow step option? What's is slow step option? Is it stepping over each instruction until the next known line reached? 2. Could the compiler add more information to make this easier? Or is it simply a matter of compiling everything with a stack frame? How about using a 3d party library compiled without debugging info / stack frame? The library could use your code compiled with debug info (i.e. by calling a callback), where the debugger should stop. thanks, Dmirty -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Handling Firebird connection
Le [...] 25/08/2014 12:13, Richard Mace a écrit : Hi Antonia, This sequence does not protect against the server disconnection between two consecutive database calls. Would you mind giving me an example of this? What I mean is that the physical TCP/IP connection between the aplication (the client) and the firebird server is not systematically tested on every function call to the library accessing the firebirs server. If you assume the following sequence of operations: MySql.Database := MyDatabase; [...] MyDatabase.Connect; (1) Mysql.Sql.text := 'select any from thedatabase'; MyTransaction.StartTransaction; (2) Mysql.Open: (3) while Mysql.EOF = False do begin // do whatever to do with database records Mysql.Next (4) end; (5) Mysql.close; (6) MyTransaction.Commit; (7) MyDatabase.Connected := False; After each statement noted (1) thru (7) the TCP/IP link initiated by the MyDatabase.Connect can be broken anywhere betwenn (1) and (7) unless you code something to test it. This can be any function looking something like a: telnet host_name(or IP address) 3050 (or whatever firebird port is used in host) issued in in a command line. In a Lazarus program you would need something like Indy ping component (any other is also OK) wich will test the firebird server awakeness. Its is really a heavy workloa anyway. I usually keep going with my former exemple. When the server connection is critical I fill in the except part some code to figure out witch is the failing part using either the exception code or the exception text itself. I can also specialize the different exception sources using the On MyException:Exception do In the top example of code I'll insert try..except's (or finally's if I don't care about exceptions) around the critical places I can't miss. But this depends on the application as well Antonio. Thanks Richard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] font.name=default
Philippe schrieb: nice. I´ll try it. (my recursive procedure worked well, not a big deal!). That's what I use, too, sometimes :-) I had some difficulty to find informations about controls, components ... if you about them you can find the reference ... but it does not help much! ... any hint? I only know from Delphi that obj.Components contains all components owned by obj, while obj.Controls contains the child controls of obj, whose Parent is obj. A TForm typically owns all its contained components (flat view), while nested (visual) controls reside in their Parent TWinControl (tree view). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On 08/25/2014 02:02 PM, Dmitry Boyarintsev wrote: On Mon, Aug 25, 2014 at 6:26 AM, C Western l...@c-m-w.me.uk mailto:l...@c-m-w.me.uk wrote: 1. How about a slow step option? What's is slow step option? Is it stepping over each instruction until the next known line reached? As I wrote that a 'perfect' step (the step you described) would be very slow, I think that this is what he means, yes. I've tried that: LCL without debug-info, created a OnFormCreate event and then I stepped into the CreateForm function. With this 'slow step' it took more than 15 minutes before the debugger stopped inside the event. So a slow step is not a real option. What could be done is adding a setting for how many levels deep the debugger will use simple single-stepping. But for now I'm happy with the current solution. 2. Could the compiler add more information to make this easier? Or is it simply a matter of compiling everything with a stack frame? How about using a 3d party library compiled without debugging info / stack frame? The library could use your code compiled with debug info (i.e. by calling a callback), where the debugger should stop. Indeed. That's one problem. Another problem is that on i386 a third-party library could use another calling convention. And for some (most?) compiler-proc's it is not possible to create a stack-frame, which also would slow down the code. What the compiler could do is adding line-info for the complete code. But I doubt that an average developers will appreciate that. An alternative could be to add line-info, but with a remark that the code could be skipped during stepping. But then we need to add something new to the Dwarf-format. Joost. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] font.name=default
thank you for these informations ... it helps! Philippe Em 25.08.2014 11:02, Hans-Peter Diettrich escreveu: Philippe schrieb: nice. I´ll try it. (my recursive procedure worked well, not a big deal!). That's what I use, too, sometimes :-) I had some difficulty to find informations about controls, components ... if you about them you can find the reference ... but it does not help much! ... any hint? I only know from Delphi that obj.Components contains all components owned by obj, while obj.Controls contains the child controls of obj, whose Parent is obj. A TForm typically owns all its contained components (flat view), while nested (visual) controls reside in their Parent TWinControl (tree view). DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus [1] Links: -- [1] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] LazReport: TfrReport.LoadFromFile question
Please file a bug report, at least the unexistant .lrf case should trigger an exception. Jesus Reyes A. El Domingo, 24 de agosto, 2014 16:56:44, Bart bartjun...@gmail.com escribió: Hi, TfrReport.LoadFromFile does not raise an exception (or return ay other indication of error) if the file does not exist and the filename has the .lrf extension. If the filename has another extension the code results in a dialog 'Unsupported FRF format'. This to me is even more bothersome, I cannot trap this in code at all, nor can I suppress the dialog. Similar to other components that have a LoadFromFile (TMemo, TSynEdit, TStringGrid to name a few), I would expect the LoadFromFile to raise an exception in both cases. Before I file this in the bigtracjker, I ask here. Maybe this is by design (compatibility with Delphi perhaps)? Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Need testers for the a new debugger
On Mon, Aug 25, 2014 at 10:47 AM, Joost van der Sluis jo...@cnoc.nl wrote: 2. Could the compiler add more information to make this easier? Or is it simply a matter of compiling everything with a stack frame? How about using a 3d party library compiled without debugging info / stack frame? The library could use your code compiled with debug info (i.e. by calling a callback), where the debugger should stop. Indeed. That's one problem. Another problem is that on i386 a third-party library could use another calling convention. And for some (most?) compiler-proc's it is not possible to create a stack-frame, which also would slow down the code. What the compiler could do is adding line-info for the complete code. But I doubt that an average developers will appreciate that. An alternative could be to add line-info, but with a remark that the code could be skipped during stepping. But then we need to add something new to the Dwarf-format. The only option I would think of, is to set break-points at all known routines and let the process run, until a break point is hit. That requires no changes to either compiler or debug-info format. I don't think that would be slow. Of course, there won't be enough of hardware breakpoints, but software breakpoints should do the trick at least of x86 platforms. I guess that what I would for duby... when I get chance to get back to it. thanks, Dmitry -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
