Re: -999 Not implemented yet.
"Mark D. Stock" <mdstock@mydassolutions.com> wrote in message news:<bvc7l9$gvg$1@terabinaries.xmission.com>...
> LUQUE Valdivia Omar wrote:
>
> > Hi,
> >
> >
> > Schema :
> > --------------
> >
> > CREATE TABLE "informix".cuentas_corrientes
> > (
> > cod_empresa character(5) NOT NULL,
> > cod_anho character(4) NOT NULL,
> > cod_tipo_documento character(3) NOT NULL,
> > cod_num_doc character(10) NOT NULL,
> > cod_tipo_analitico character(1),
> > cod_analitico character(15),
> > cod_tipo_doc_ent character(3),
> > num_serie character(4),
> > num_documento character(20),
> > cod_pagar_cobrar character(1),
> > flg_acr_deb character(1),
> > cod_moneda character(3),
> > dtm_documento datetime YEAR TO MINUTE,
> > des_documento lvarchar,
>
> Yup, you cannot select extended data types (things like LVARCHAR, BOOLEAN,
> etc.) remotely like this. If you explicitly name all the other columns in
> your select and omit des_documento, then it will work.
>
> Please submit a feature request to IBM for this to be "fixed". The more
> that do, the more chance it will get fixed.
>
> Cheers,
> --
> Mark.
>
> +----------------------------------------------------------+-----------+
> | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
> | Mydas Solutions Ltd http://MydasSolutions.com |///// / //|
> | +-----------------------------------+//// / ///|
> | |We value your comments, which have |/// / ////|
> | |been recorded and automatically |// / /////|
> | |emailed back to us for our records.|/ ////////|
> +----------------------+-----------------------------------+-----------+
>
> sending to informix-list
For all who read this:
in the 9.4 documentation page 4-52 of the IBM Informix Guide to SQL:
Syntax :-
"The LVARCHAR data type is a built-in opaque type. Like other opaque
types, it cannot be retrieved by a distributed query of a remote
database."
Thus until opaque types are included in distributed queries, which is
what you are trying to do, you'll
need to use another strategy. You could use a stored procedure as they
allow opaque types to be "distributed"
CONNECT TO @svr1;
database db1;
create table customer
(
unique_index int,
reginstructions lvarchar
);
insert into customer (unique_index, reginstructions) VALUES (1000, '1234567');
create procedure chibble
(
in_int int
)
returning lvarchar; DEFINE retstring lvarchar;
select RegInstructions INTO retString from customer where
unique_index = in_int;
RETURN retstring;
end procedure;
database db2;
execute procedure dataconv:chibble( 1000);
BTW this is written without the use of a server to test it on!
IAN LOWSON
DNI Computing Consultants
York