× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thank you for your information. I will suggest them to my team.

Some more precisions:

1. I cannot change to 65535 because file contain data which were entered
with a specific CCSID and need a conversion to ensure the graphic
representation if the CCSID of another job differs.

2. Referential integrity need to have the same field(s): it means same type,
same length and same CCSID.

Michel-Claude Ducrest
tel. +41 21 924 16 14
fax +41 21 924 2882


-----Original Message-----
From: Vern Hamberg [mailto:vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday,6. August 2003 16:03
To: Midrange Systems Technical Discussion
Subject: RE: CCSID and SQL


A couple ideas:

1. What if you put CCSID 66535 on both fields in the DDS. That's a 
"leave-it-alone" setting, IIRC.

2. Could you set up referential integrity with foreign keys and *DELETE 
*RESTRICT? Then you'd get a message if records exist in the dependent 
files. I don't know the CCSID implications.

3. Or use EXCEPTION JOIN on the key fields - then the only records returned 
are those with nothing in dependent files. Add all the key fields to the 
example, of course. It might be faster to use the key fields only in the 
field list - might allow index-only processing, esp. in the second version 
below.

     select * from master exception join detail1 on master.fld1 = 
detail1.fld1 exception join detail2 on master.fld1 = detail2.fld1

   This is the same, I think, as correlated subqueries in NOT EXISTS
predicates

     select * from master where not exists (select * from detail1 where 
fld1 = master.fld1) and not exists (select * from detail2 where fld1 = 
master.fld1)

4. There's always READ master with SETLL EQ on both detail files. Would 
CCSID matter there?

One thing I recommend to simulate multiple-format logicals with a UNION is 
to use the common key fields, then some identifier for each type of record 
(record indicator in RPGII terms), then a concatenation of all remaining 
fields that I need into a character field. When fetched, I'd use a SELECT 
CASE on the identifier to move that character field to a DS (RPG) or struct 
(C/C++).

I thought you could have VIEWs in the subselects that comprise a UNION. Is 
this not true? I know that only in V5R2 can a VIEW be constructed from a
UNION.

HTH

Vern

At 08:09 AM 8/6/2003 +0200, you wrote:
>Vern,
>
>Our problem is: verify, before deleting a row in a master file, that the
>item is not present in two other files.
>We also try first to use SQL UNION.  But in our case, the two physical
files
>have the same key, but different format and we would use "UNION of VIEW",
>which is not possible. It is the reason we must use logical multi-format.
>CCSID keyword exist at field level, but our application must work anywhere
>in the world, and we cannot hardcode the CCSID value.
>Is there any other solution?
>
>Michel-Claude Ducrest
>tel. +41 21 924 16 14
>fax +41 21 924 2882
>
>
>-----Original Message-----
>From: Vern Hamberg [mailto:vhamberg@xxxxxxxxxxxxxxxxxxxxxxxxx]
>Sent: Tuesday,5. August 2003 16:38
>To: Midrange Systems Technical Discussion
>Subject: Re: CCSID and SQL
>
>
>Michel-Claude
>
>Great question.
>
>My guess is that SQL uses intermediate results, translating the fields in
>question as needed. DDS files need to match - is there a keyword for CCSID
>at field level - I forget.
>
>Of course, a multi-format logical is not the same as JOIN in SQL - the
>logical is more like an SQL UNION. My assumption fits the UNION scenario
>better.
>
>Regards
>
>Vern
>
>At 10:56 AM 8/5/2003 +0200, you wrote:
> >We encountered the following problem:
> >
> >We try to create a logical file with multi-format (I know, it is not the
> >best way). The first physical file referenced by the logical one, has a
> >CCSID of 500, and the second one has a CCSID of 297. So the creation
abort
> >with a CPF or CPD error. That's normal. To be able to create the
> >multi-format, we have to accord both physical file CCSID first. That's
what
> >we do now.
> >
> >My question is the following:
> >SQL join request is able to work on two different CCSID physical file, if
> >the join fields are identical. Why is it not possible with DDS multi
>format?
> >
> >Michel-Claude Ducrest
> >tel. +41 21 924 16 14
> >fax +41 21 924 2882
>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>or email: MIDRANGE-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>To post a message email: MIDRANGE-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>or email: MIDRANGE-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.