> except on E : ?TADOException? (what type to use?) > if not VerifyPropertyOfAdoException(E) then > raise E; > end;
I'm not sure I understand you here. => ok, EADOError => Does EADOError has some interesting property to understand what kind of error? I mean a property easly to manage in the code [that is, not just the string-message]. Thank you for help. As wrote to Mike, I believe I will take off the nested try-except and use a PreCheckQueryProperties function. I will upgrade it every time I realize some new condition for which a) I have to upgrade the code b) I can drop that row-transfer and so just don't execute the SQL. Thank you again. Mauro. ----- Original Message ----- From: "Theodoros Bebekis" <[email protected]> To: <[email protected]> Sent: Tuesday, February 10, 2009 2:00 PM Subject: Re: [delphi-en] TADOQuery / TADOConnection O/H mauro russo Ýãñáøå: > but what [non-String] property of the exception to check to make a > selection? > => > try > MyADOQuery.ExecSQL(); > except on E : ?TADOException? (what type to use?) > if not VerifyPropertyOfAdoException(E) then > raise E; > end; I'm not sure I understand you here. You can use any Exception type in a try..catch block. You set the most general type to be the last one. try except on E: EADOError do begin end; on E: EDatabaseError do begin end; on E: Exception do begin end; else // impossible. Exception is the most general trap end; or you can try except on E: Exception do begin if (E is EADOError) then else if (E is ESomeOtherError) then end; end; end; > http://msdn.microsoft.com/en-us/library/ms680895(VS.85).aspx >>> > (from the referenced web page:) > Depending on the Connection object's Attributes property, calling either > the > CommitTrans or RollbackTrans methods may automatically start a new > transaction. If the Attributes property is set to adXactCommitRetaining, > the > provider automatically starts a new transaction after a CommitTrans call. > If > the Attributes property is set to adXactAbortRetaining, the provider > automatically starts a new transaction after a RollbackTrans call. I always avoid using the xxxxRetaining settings with connections. Retaining means commit or rollback but RETAIN the transaction context in the server for speed or other reasons. I avoid doing that. Regarding ADO nested transactions I explain why not to use that xxxxRetaining flags in the example project from my seminars (I'm a Delphi trainer) I've sent privately to you. I tried to upload it to the files area of this list but no luck due to moderation restrictions. > > The default property of TADOConnection [I am using default] are: no > adXactCommitRetaining actived and no adXactAbortRetaining actived. > In fact, also if I did not know about these properties, I wrote the code > having in mind that a transaction is open only if I explictly call > BeginTrans(). > Or, if I use an ExecSQL before to call BeginTrans(), I always think that a > mini-transaction is automatically open and then closed soon after > the ExecSQL work end. I'm not sure about that and have no time to check it out, but possibly a transaction is started implicitly when there is not an explicit one. > Well, if you believe I should not use nested transactions, then I need to > avoid the transaction closure on an ExecSQL-ADOexception > and using that "VerifyPropertyOfAdoException". Nested transactions is not evil. And in some cases maybe the only way to go. They just require carefull handling. > If it is not possible, I believe I will try to understand in what cases > the > ExecSQL can generate an exception [I know already the most important, What about a database constraint violation? A non existent table or field? A missing parameter? A not properly formatted string? In all of those situations an exception will be raised. Trap explicitly what you believe you have to handle with a narrow and special logic, i.e. a unique constraint violation, and place at the bottom of the except..end block the most wide trap available, an Exception trap. try except on A: EClass1 do; on B: EClass2 do; on C: Exception do ; end; > but no all cases] and then I will use: > > //no try > if PreCheckQueryProperties(MyADOQuery) then > MyADOQuery.ExecSQL(); > //no except -- Regards Theo ------------------------ Theo Bebekis Thessaloniki, Greece ------------------------ The resource you are looking for has been removed, had its name changed, or is temporarily unavailable. ------------------------ Greek_Delphi_Prog : a Delphi Programming mailing list in Greek at http://groups.yahoo.com/group/Greek_Delphi_Prog CSharpDotNetGreek : A C# and .Net mailing list in Greek language at http://groups.yahoo.com/group/CSharpDotNetGreek atla_custom : a Unisoft Atlantis Customization mailing list at http://groups.yahoo.com/group/atla_custom ------------------------ ------------------------------------ ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [email protected]! Groups Links ---------- Questa email è stata verificata dal sistema centralizzato antivirus della UniPlan Software [Non-text portions of this message have been removed] ------------------------------------ ----------------------------------------------------- Home page: http://groups.yahoo.com/group/delphi-en/ To unsubscribe: [email protected]! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/delphi-en/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/delphi-en/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
