> Em 16/02/2016 19:55, Leyne, Sean escreveu:
> >
> >
> >>> What if one were to replace some contexts with calls to SPs that
> >>> executed those actions? Would the context counts from the SPs be
> >>> added to those of the trigger?
> >>
> >> Nope. The context limit is bound to a request. Every
>
Em 16/02/2016 19:55, Leyne, Sean escreveu:
>
>
>>> What if one were to replace some contexts with calls to SPs that
>>> executed those actions? Would the context counts from the SPs be
>>> added to those of the trigger?
>>
>> Nope. The context limit is bound to a request. Every procedure/trigger
> > What if one were to replace some contexts with calls to SPs that
> > executed those actions? Would the context counts from the SPs be
> > added to those of the trigger?
>
> Nope. The context limit is bound to a request. Every procedure/trigger has its
> own request, thus a separate context
16.02.2016 22:04, Helen Borrie wrote:
>
> What if one were to replace some contexts with calls to SPs that
> executed those actions? Would the context counts from the SPs be
> added to those of the trigger?
Nope. The context limit is bound to a request. Every procedure/trigger
has its own reques
Wednesday, February 17, 2016, 7:03:12 AM, Dmitry wrote:
> 16.02.2016 20:07, Leyne, Sean wrote:
>>
>> Would INSERTs (as below) to a table count as a context?
> Sure. Every table reference is a context. Be it SELECT/INSERT/whatever.
> For UPDATE it takes two contexts.
What if one were to replace s
16.02.2016 20:07, Leyne, Sean wrote:
>
> Would INSERTs (as below) to a table count as a context?
Sure. Every table reference is a context. Be it SELECT/INSERT/whatever.
For UPDATE it takes two contexts.
Dmitry
--
Site
Dmitry,
> > > I always thought that this error was about table/view references,
> > > not about old/new context variables.
> > > What is the source of the error?
> >
> > OLD/NEW occupy two contexts, the rest is from somewhere else. Do you
> > have computed fields with embedded selects that are be
> > I always thought that this error was about table/view references, not
> > about old/new context variables.
> > What is the source of the error?
>
> OLD/NEW occupy two contexts, the rest is from somewhere else. Do you
> have computed fields with embedded selects that are being accessed via th
> BLR uses a byte for context variables. It's my fault. Ann will explain that
> I am
> a victim of the 16 bit depression.
More like *8* bit depression, since the limit is 255 variables.
Sean
--
Site24x7 APM Insigh
16.02.2016 18:58, Leyne, Sean wrote:
>
> We are running into an interesting problem while trying to implement
> some triggers. We are getting the following message:
> Cannot commit transaction:
> Undefined name.
> Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255.
> We have tri
BLR uses a byte for context variables. It's my fault. Ann will explain
that I am a victim of the 16 bit depression. Not in my wildest dreams
could I image that your run of the mill $35 SMP computer would come with
a gigabyte of memory.
There probably isn't a workaround.
On 2/16/2016 10:58
All,
We are running into an interesting problem while trying to implement some
triggers. We are getting the following message:
Cannot commit transaction:
Undefined name.
Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255.
We have tried to break up the trigger into multiple
Hello, All.
Do I understand right that because HalfStaticArray is derived from
AutoStorage, it
cannot be used in dynamically allocated objects?
What array class can be used there?
--
WBR, SD.
--
Site24x7 A
13 matches
Mail list logo
