|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
AW: dbproc behaviour after drop and (re)create table
From: Anhaus, Thomas (thomas.anhaus
sap.com)
Date: Fri Oct 07 2005 - 08:55:36 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jean-Michel OLTRA wrote :
> bonjour,
>
>
>Le vendredi 07 octobre 2005, Anhaus, Thomas a écrit...
>
>
>> objects have no knowledge about the db-procedures using it.
>> This means that today you have to recreate the db-procedures by hand
>> whenever a change of an object accessed inside
>> the procedure requires it.
>
>What does "requires" exactly means ? The dropped table had been
>recreated with the .command file of a DATAEXTRACT. I would say that old
>(the dropped) and new (the recreated) are identical objects. No ?
>
>--
>jm
>
>
>
>--
>MaxDB Discussion Mailing List
>For list archives: http://lists.mysql.com/maxdb
>To unsubscribe:
>http://lists.mysql.com/maxdb?>unsub=thomas.anhaus
sap.com
>
>
I agree, if the old and new table definition do not differ, it shouldn't be necessary to recompile the db-procedure.
Recompilation is necessary for example, if the data type of a column is changed.
But you mentioned a problem with NEXTVAL. Is it possible, that a sequence that has been recreated is used inside your procedure ?
If this is true and the sequence is accessed directly (i.e. without SQL) this would explain your problems.
Best Regards,
Thomas
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]