Subject | Re: [IB-Architect] SQL Statement Depandance Mapping |
---|---|
Author | Dalton Calford |
Post date | 2000-06-30T19:45:07Z |
Hi Jim,
make modifications to them. I always looked at it that if I screw up,
it is my fault, not the engines. What I always wanted was a breakdown
of the different tables that are touched for each operation. With that
information, I could create a client that directly touched these tables
following my own extended scripting language. I guess I will have to
wait for the source for that.
The reason I am asking is, if we have a full understanding of blr, could
we extend IB's functionality without needing to touch the underlying
engine.
For example, If we have a compiled blr routine that was passed a sql
statement, is there enough veritility in the blr language to build a
parser that could build another blr routine from the parsed input?
We could create a stored procedure that produces dynamic sql. All
without touching the engine. Even though such a method is alot of work
and beyond the average programer, I would prefer such a method if it was
fast enough.
I look at IB as a low level data manipulation language. I know that for
most of my needs, I can program the needed routines into SP/Trigger
language, no matter how complex (but my SP based random number generator
is still producing a predictable sparse pattern matix - I have more work
to do on it...)
let her be until she has a break to come up for air....
bother trying to make it pretty or filling in lost parts. Just let the
rest of us Interbase junkies tear into it and maybe we will have
somthing in short order.
best regards
Dalton
> If you omit the word "safely" the answer is just about everything.I always liked the fact that I could read the system tables, or even
> In my youth I thought active system tables were a great idea. I've
> since changed by mind.
make modifications to them. I always looked at it that if I screw up,
it is my fault, not the engines. What I always wanted was a breakdown
of the different tables that are touched for each operation. With that
information, I could create a client that directly touched these tables
following my own extended scripting language. I guess I will have to
wait for the source for that.
> Touch RDB$FORMATS (or whatever) and the world will end. Stick bad BLRWhen you built BLR, did you give it access to all the low level api's?
> into any number of system tables and gruesome things may happen.
The reason I am asking is, if we have a full understanding of blr, could
we extend IB's functionality without needing to touch the underlying
engine.
For example, If we have a compiled blr routine that was passed a sql
statement, is there enough veritility in the blr language to build a
parser that could build another blr routine from the parsed input?
We could create a stored procedure that produces dynamic sql. All
without touching the engine. Even though such a method is alot of work
and beyond the average programer, I would prefer such a method if it was
fast enough.
I look at IB as a low level data manipulation language. I know that for
most of my needs, I can program the needed routines into SP/Trigger
language, no matter how complex (but my SP based random number generator
is still producing a predictable sparse pattern matix - I have more work
to do on it...)
> Ann's problem.Ann is dealing with Dale and lawyers on a regular basis, I think I will
let her be until she has a break to come up for air....
> We've got a copy of the TROFF BLR book. When Ann has a few spare:) if it is not bound by legal complexities, post it as is, don't even
> cycles (which ain't going to happen this week or even next) she's
> promised to make a pass at it.
bother trying to make it pretty or filling in lost parts. Just let the
rest of us Interbase junkies tear into it and maybe we will have
somthing in short order.
best regards
Dalton