On Fri, 17 Feb 2006 13:04:37 +0100, Rob Verschoor wrote:

> I don't think you can implement that sort of check with 100% certainty if
yep, tough cookie!

> you assume the syscomments text could be modified. In any case, the
> query tree would not be unique: different stored procs could well have
> the same query tree.
Okay, if that's the case then it looks my effort is doomed!
Unless you mean that a different stored procedure could be defined the
same and thus produce the same query tree. I wouldn't care about that. I
only care that the stored procedure I will call hasn't been "patched" with
for instance an extra delete, insert or whatever statement!

I will try to retrieve the "hidden" column from the CT lib calls and
experiment a bit... it is Friday anyway!

Thanks again Rob!

Hans.


>
> Rob V.
>
> "Hans Kramer" <noms@xs4all.nl> wrote in message
> newsan.2006.02.17.11.56.48.193388@xs4all.nl...
>> Thanks Rob,
>>
>> If it is not accessible thru SQL I guess I am out of luck.
>>
>> I wanted to use this information from the client side to make sure that
>> I am executing the correct version of the stored procedure in question.
>>
>> The syscomments table can be edited so is no good (but will do for most
>> purposes including perhaps mine) and just using the OBJECT_ID could
>> help as well. However, the query tree should uniquely describe the
>> stored procedure (actually I was hoping that, perhaps naively).
>> Producing a strong hash value of that data would be enough.
>>
>> This sounds silly, however, it is useful in some cases in which "we
>> cannot" (better phrased: want to) trust the DBA (how is that posssible
>> ;-). Of course the question that immediately rises, can we trust the
>> application side :-) :-) Well it is more legal mumbo jumbo (or in my
>> case Good Clinical Practice 21 CFR Part 11)
>>
>> Hans.
>>
>> On Fri, 17 Feb 2006 12:18:58
>>
>> On Fri, 17 Feb 2006 12:18:58 +0100, Rob Verschoor wrote:
>>
>> > The information in sysprocedures is stored in a kind of 'hidden'
>> > column, i.e. not accessible through SQL. Even if it were accessible,
>> > it would
> not
>> > be useful at all, since there is no way to display what's in there.
>> > Note that it doesn't contain a query plan BTW -- that only exists in
>> > the procedure cache, and is generated by the optimizer after the
>> > query tree has been read from disk.
>> >
>> > HTH,
>> >
>> > Rob
>> > ------------------------------------------------------------- Rob
>> > Verschoor
>> >
>> > Certified Sybase Professional DBA for ASE 12.5/12.0/11.5/11.0 and
>> > Replication Server 12.5 / TeamSybase
>> >
>> > Author of Sybase books (order online at www.sypron.nl/shop): "Tips,
> Tricks
>> > & Recipes for Sybase ASE" "The Complete Sybase Replication Server
>> > Quick Reference Guide" "The Complete Sybase ASE Quick Reference
>> > Guide"
>> >
>> > mailto:rob@YOUR.SPAM.sypron.nl.NOT.FOR.ME http://www.sypron.nl Sypron
>> > B.V., P.O.Box 10695, 2501HR Den Haag, The Netherlands
>> > -------------------------------------------------------------
>> >
>> > "Hans Kramer" <noms@xs4all.nl> wrote in message
>> > newsan.2006.02.17.10.58.13.453947@xs4all.nl...
>> >> Hi,
>> >>
>> >> Is there a method to get more information about the query tree then
>> >> I can get from simply querying the sysprocedures table?
>> >>
>> >> For instance:
>> >> select * from sysprocedures where id=OBJECT_ID("test2");
>> >> type id sequence status number
> version ------ -----------
>> >> ----------- ------ ------ -----------
>> >> 2 655442478 0 1152 1 12500 2
>> >> 655442478
>> >> 1 1152 1 12500 2 655442478 2
>> >> 1152 1 12500 2 655442478 3 1152
>> >> 1
>> >> 12500 2 655442478 4 1152 1 12500 2
>> >> 655442478 5 1152 1 12500 2 655442478
>> >> 6 1152 1 12500 2 655442478 7
>> >> 1152
>> >> 1 12500 2 655442478 8 1152 1
>> >> 12500 2 655442478 9 1152 1 12500 2
>> >> 655442478 10 1152 1 12500 2 655442478
>> >> 11 1152 1 12500
>> >> This doesn't tell me a whole lot about the query tree!
>> >>
>> >> Thanks,
>> >>
>> >> Hans.
>> >>
>> >>
>> >>
>>