🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: borland.public.interbase.sql
5 messages
5 total messages Started by Isaac Sat, 14 Jun 2008 17:20
debug stored procedures
#224
Author: Isaac
Date: Sat, 14 Jun 2008 17:20
11 lines
1287 bytes
Hello,
I have IBExpert and like other tools I can debug stored procedure from 
the database itself but I wonder if there is a tool or something that 
can let me step through stored procedure from inside Delphi as the 
application in debug mode ?

because I could miss easily an action done by Delphi to the database so 
when I debug my stored procedure I see every thing is all right but 
result was different I test the application from Delphi - I hope I was clear

Thanks
Re: debug stored procedures
#226
Author: Wayne Niddery (TeamB)
Date: Sat, 14 Jun 2008 20:07
27 lines
2422 bytes
"Isaac" <no@no.com> wrote in message 
news:4853fd43$1@newsgroups.borland.com...
> I have IBExpert and like other tools I can debug stored procedure from the 
> database itself but I wonder if there is a tool or something that can let 
> me step through stored procedure from inside Delphi as the application in 
> debug mode ?
>
> because I could miss easily an action done by Delphi to the database so 
> when I debug my stored procedure I see every thing is all right but result 
> was different I test the application from Delphi - I hope I was clear


The stored procedure debugger will let you see the parameters that were 
passed, so if you supply the same ones you know your Delphi program  would 
be sending (which you can see in the Delphi debugger) then you *must* get 
the same  results.

However, it is important to understand that InterBase does not provide any 
actual debugging interface and the debugger you are using is in fact 
*emulating* the execution of the stored procedure and stepping through its 
emulation, not the *actual* InterBase execution. While in most cases it is 
going to be accurate (the developers of it try very hard), there can 
occasionally be differences.

-- 
Wayne Niddery - TeamB (www.teamb.com)
Winwright, Inc. (www.winwright.ca) 
Re: debug stored procedures
#227
Author: Isaac
Date: Sat, 14 Jun 2008 20:52
21 lines
2020 bytes
OK but I encounter today a very strange scenario:
first after I modified my stored procedure I run Delphi to see what will 
go, I set before 3 triggers (after insert, after update and after 
delete) for "table a" which they all call one procedure with different 
parameters

then when I try to post an inserted record I get exception error that I 
try to post a null value to a none null field The big surprise is that 
field is not in "table a" I insert the record into but in another table 
"table b" which I only touch it with the update statement and "table a" 
has foreign keys on table "table a"

after alot of going around my self I deactivate the trigger which call 
the procedure then I  tried again to insert  the record and it is 
inserted normally so reactivate the trigger and try again to insert the 
record *without any change in the sql* the record inserted with the same 
data I tried before without any error !!!!!!!!!

can you explain that phenomena ??

Thanks
Re: debug stored procedures
#236
Author: Martijn Tonies
Date: Mon, 16 Jun 2008 06:58
37 lines
2592 bytes
> OK but I encounter today a very strange scenario:
> first after I modified my stored procedure I run Delphi to see what will
> go, I set before 3 triggers (after insert, after update and after
> delete) for "table a" which they all call one procedure with different
> parameters
>
> then when I try to post an inserted record I get exception error that I
> try to post a null value to a none null field The big surprise is that
> field is not in "table a" I insert the record into but in another table
> "table b" which I only touch it with the update statement and "table a"
> has foreign keys on table "table a"
>
> after alot of going around my self I deactivate the trigger which call
> the procedure then I  tried again to insert  the record and it is
> inserted normally so reactivate the trigger and try again to insert the
> record *without any change in the sql* the record inserted with the same
> data I tried before without any error !!!!!!!!!
>
> can you explain that phenomena ??

Metadata caching on the server side by the IB Server process.

By re-activating the trigger, you're causing that part of the cache
to get flushed. IB will re-load the metadata of the trigger and
procedure from the database and load the new code.


-- 
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com
Re: debug stored procedures
#240
Author: Isaac
Date: Tue, 17 Jun 2008 16:26
11 lines
1379 bytes
Martijn Tonies wrote:
> Metadata caching on the server side by the IB Server process.
>
> By re-activating the trigger, you're causing that part of the cache
> to get flushed. IB will re-load the metadata of the trigger and
> procedure from the database and load the new code.
>
>
>   
Oh that doing it , Many Thanks for clearing this to me *Appreciate your 
concern*
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads