Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Michelle reported random error 9905 (No extended type information for domain) when loading a procedure with a MULTISET of VARCHARs on Informix 9 and 10; changing to CHAR avoided it. Zachi said he saw similar -9905/-9628 bugs fixed in 11 and cleared extended type records manually. superboer7 pointed to an older 9628 bug and advised raising PC_POOLSIZE, DS_POOLSIZE and hash sizes. Another poster said to open an IBM case. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hello,
On random occurrences when a database is first created or updated
and a procedure containing a multiset with varchars is loaded I get
the following error:
9905: [Internal] No extended type information for domain.
This is a random and seldom occurrence, but happens enough to cause
a lot of trouble. It's been seen in both Informix 9 and 10 and is not
machine/platform specific. Changing the varchars to chars seems to
rectify the problem, but it is a solution I cannot use.
Has anybody seen this before? Any ideas?
On 30 Dec, 20:01, Michelle <shannon_c...@hotmail.com> wrote:
> Hello,
>
> On random occurrences when a database is first created or updated
> and a procedure containing a multiset with varchars is loaded I get
> the following error:
>
> 9905: [Internal] No extended type information for domain.
>
> This is a random and seldom occurrence, but happens enough to cause
> a lot of trouble. It's been seen in both Informix 9 and 10 and is not
> machine/platform specific. Changing the varchars to chars seems to
> rectify the problem, but it is a solution I cannot use.
>
> Has anybody seen this before? Any ideas?
Open a case with IBM.
On Dec 30, 3:01 pm, Michelle <shannon_c...@hotmail.com> wrote:
> Hello,
>
> On random occurrences when a database is first created or updated
> and a procedure containing a multiset with varchars is loaded I get
> the following error:
>
> 9905: [Internal] No extended type information for domain.
>
> This is a random and seldom occurrence, but happens enough to cause
> a lot of trouble. It's been seen in both Informix 9 and 10 and is not
> machine/platform specific. Changing the varchars to chars seems to
> rectify the problem, but it is a solution I cannot use.
>
> Has anybody seen this before? Any ideas?
I have seen similar bugs (-9905 and -9628) before, reported them and
IBM fixed them in some 11 release. The problem is that MULTISET
requires two extended data types: one for the ROW and one for the
MULTISET itself. Sometimes, the records of either one of them are
missing (or duplicated), and this causes stored procedures (and SQLs)
to fail. I had to manually clear the relevant records from the
extended data type sys tables (not something for the faint of heart!)
and restart the engine (otherwise these records might still be in the
cache) and then recreate the stored procedures (or SQLs). You might be
able to get away with a database restart and then recreate the stored
procedures - if you are lucky...
Happy New Year,
Zachi
sounds like an occasion of an oldie:
130885 9628 TYPE NOT FOUND USING SPL WHEN ROUTINE/EXT TYPE
CACHE IS HAMMERED ERROR IS STORED IN SYSPROCPLAN
up the values for PC_POOLSIZE, DS_POOLSIZE, DD_HASHSIZE,DD_HASHMAX,
PC_HASHSIZE,DS_HASHSIZE etc.
Superboer.
On 30 dec, 23:27, Zachi <zklop...@gmail.com> wrote:
> On Dec 30, 3:01 pm, Michelle <shannon_c...@hotmail.com> wrote:
>
> > Hello,
>
> > On random occurrences when a database is first created or updated
> > and a procedure containing a multiset with varchars is loaded I get
> > the following error:
>
> > 9905: [Internal] No extended type information for domain.
>
> > This is a random and seldom occurrence, but happens enough to cause
> > a lot of trouble. It's been seen in both Informix 9 and 10 and is not
> > machine/platform specific. Changing the varchars to chars seems to
> > rectify the problem, but it is a solution I cannot use.
>
> > Has anybody seen this before? Any ideas?
>
> I have seen similar bugs (-9905 and -9628) before, reported them and
> IBM fixed them in some 11 release. The problem is that MULTISET
> requires two extended data types: one for the ROW and one for the
> MULTISET itself. Sometimes, the records of either one of them are
> missing (or duplicated), and this causes stored procedures (and SQLs)
> to fail. I had to manually clear the relevant records from the
> extended data type sys tables (not something for the faint of heart!)
> and restart the engine (otherwise these records might still be in the
> cache) and then recreate the stored procedures (or SQLs). You might be
> able to get away with a database restart and then recreate the stored
> procedures - if you are lucky...
>
> Happy New Year,
>
> Zachi
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.