Help on UDO in 4GL

Hi: Could someone give me some clues on how to refer and declare an (User defined Object) UDO in a 4GL program. My INFORMIX version is IDS.2000 (9.2) Sample Scenario ============ Row Type ======== create row type name_t ( first_nm varchar(35, 1), last_nm varchar(35, 1) ) Table: ==== create table my_udo ( cust_no serial not null, comapnmy_nm varchar(35, 1), cust_nm name_t ); 4GL Program ========== database test_db define gr_udo record cust_no integer, company_nm char(35), contact_nm <HOW DO I DECLARE FOR ROW TYPE> end record --- I tried like contact_nm name_t <NO LUCK> --- contact_nm row <NO LUCK> main -- Yet to Code end main ============== Any suggestions on the matter will be of great help. Thanks in advance.

Chetan Anand wrote: > Could someone give me some clues on how to refer and declare an (User > defined Object) UDO in a 4GL program. Succinctly, you can't. I4GL does not have the faintest idea about any of the data types that are not in the 7.30 (read 4.00 through 7.30) databases. > My INFORMIX version is IDS.2000 (9.2) > > Sample Scenario > ============ > > Row Type > ======== > > create row type name_t > ( > first_nm varchar(35, 1), > last_nm varchar(35, 1) > ) > > [...extended example using about type omitted...] FWIW, I see no particular value in the ',1' part of the VARCHAR specs. It forces the engine to allocate 2 bytes (one for the count, one for the mandatory byte of data) when it might otherwise allocate just one byte. It is not the same as specifying NOT NULL (which you can't specify in a row type anyway, if the alarm bells going off in my head mean anything other than the dog needs walking:-). -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.95 -- see http://www.perl.com/CPAN #include <disclaimer.h>

Chetan Anand wrote: > Hi: > > Could someone give me some clues on how to refer and declare an (User > defined Object) UDO in a 4GL program. > > My INFORMIX version is IDS.2000 (9.2) > > Sample Scenario > ============ > > Row Type > ======== > > create row type name_t > ( > first_nm varchar(35, 1), > last_nm varchar(35, 1) > ) > > Table: > ==== > > create table my_udo > ( > cust_no serial not null, > comapnmy_nm varchar(35, 1), > cust_nm name_t > );> > 4GL Program > ========== > > database test_db > > define gr_udo record > > cust_no integer, > company_nm char(35), > contact_nm <HOW DO I DECLARE FOR ROW TYPE> > > end record > > --- I tried like contact_nm name_t <NO LUCK> > --- contact_nm row <NO LUCK> > > main > > -- Yet to Code > > end main > > ============== > > Any suggestions on the matter will be of great help. > > Thanks in advance. You can try something like. DEFINE gr_udo RECORD LIKE my_udo.* -- Compliments of QueriX -------------------------------------------------------------------------------------------------- QueriX 4GL Compilers are Informix 4GL Compatible, and Connection to other RDBMS such as Oracle. Hydra 4GL Compiler (Compatible with I4GL) Compile once, run everywhere Phoenix Windows GUI. (Front End to 4GL) Chimera Java GUI The only GUI you will ever need... (Front End to 4GL) Arachne Web Technology (Front End to 4GL on the Web) For more details visit: http://www.querix.com/ ---------------------------------------------------------------------------------------------------

mercredi 19 janvier 2000 7:41 Jonathan Leffler <jleffler@earthlink.net> a écrit dans message news:38855C9B.C57ADB1B@earthlink.net... > > <snip snip> > FWIW, I see no particular value in the ',1' part of the > VARCHAR specs. > It forces the engine to allocate 2 bytes (one for the > count, one for > the mandatory byte of data) when it might otherwise > allocate just one > byte. It is not the same as specifying NOT NULL (which > you can't > specify in a row type anyway, if the alarm bells going off > in my head > mean anything other than the dog needs walking:-). > Oh dear I just changed several columns and accepted the ',1' default. I have a database (7.24UC10 under HP-UX 10.20 on a 4-processor HP9000 K 400) which runs dog slow. Anyway, I was reading the FMs and they suggested replacing CHAR fields with VARCHARS where the fields are generally not full. So I was playing with this one table which only has about 500000 rows (rowsize acc. to systables is 441) but each row has around 140 or so chars of empty text variables. There are two 60 char fields which are always empty. I'm fairly certain I can change the schema with impunity and these fields don't show in any screens or reports. May I ask if the denizens of c.d.i think this heavily-used table will be more efficient with CHARS or VARCHARS? > -- > Jonathan Leffler (jleffler@informix.com, > jleffler@earthlink.net) > Guardian of DBD::Informix v0.95 -- see > http://www.perl.com/CPAN > #include <disclaimer.h> > -- Andrew Pearson - un animal avec beaucoup de fonctions interactives. Parlez et riez ensemble. Il connait 800 mots et bruits. Réagit à la lumière et au bruit. Ses movemements sont très réalistes! Version anglais.