Adriano dos Santos Fernandes wrote:

> Alexandre Benson Smith wrote:
>
>> If an application has long running transactions, it's a problem of the
>> developer to make it poor designed and would have the old (buggy) SP
>> code running during the whole day...
>>
> Not true... Statement is prepared in transaction1, transaction1 is
> committed and statement is still valid to be used until connection is
> closed, and this is not poor designed application.
>

Yes I know...

What I said is...

Until transaction commits the "application" would see the prior version,
when a new transaction starts, the new version would be executed.

For prepared statements (DSQL) the engine should re-prepare the
statement when a new vision of the metadata is available (because a new
transaction starts) if the statement could be prepared ok, it's
transparent to the application developer, if it fails (missing column or
something like that) an exception would be raised, the client app should
have provision to handle such errors.

The main point of my talking is that each modification of a object must
"create" a new object in memory (cache) as it was a completely different
object, the engine would find the correct version to use when look for
metadata based on the transaction that are asking for such object

Let's supose we have (I am not talking implementation detail, just a
rough example :) ):

create view vRelations (RelationName) as select rdb$relation_name from
rdb$Relations;

It would be cached as with a name vRelations_000

When someone alters it to

recreate view vRelations (RelationName, BLR) as select
rdb$relation_name, rdb$view_blr from rdb$Relations;

This second version would be cached as vRelations_001

The point I am trying to say is that ecah version would be a completelly
different object, with distinct atributes that has the same name and the
correct "version" would be used acordling to the active transaction.

ObjectName InstanceName Transaction
vRelations vRelations_000 1
vRelations vRelations_001 3

Every transaction greater than or equal to 3 would have the
vRelations_002 when ask for vRelations

> More tomorrow (I mean, after sleep). :-)
>
>
> Adriano
>
>

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br