× 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.



Hi,

>>(dammit, who needs journaling or commitment control 
>>on a temporary file?!?!) 

Instead of creating a table with CREATE TABLE in the QTEMP library, 
you should use the SQL-Command DECLARE GLOBAL TEMPORARY TABLE,
which is the SQL way to create a temporary table.

DECLARE GLOBAL TEMPORARY TABLE WTGRPW 
as (select   CID from WTCONT CO
       where CO.U01010 = '1')             
WITH DATA
WITH REPLACE

WITH REPLACE will delete an existing table with the same name in the QTEMP
and CREATE a new table.
Specifying WITH DATA will fill the table. If DEFINITION ONLY is specified
instead, an empty table is created in the QTEMP. To fill this temporary
table, you can use an insert statement like you did before, but WITH NC is
not required.

>>In one of my experiments, I tried a "FOR READ ONLY" clause 
>>on the SELECT, knowing that's supposed to speed up the 
>>"open" operation, and it bombed with a message to the 
>>effect that such clauses could not be used on embedded 
>>SELECTs.

The select statement in an insert statement is READ ONLY by nature.
There will never be an UPDATE for this statement.
That's why specifying FOR READ ONLY it's not only not necessary, but not
allowed.

The FOR READ ONLY or FOR FETCH ONLY clauses will only affect cursors.
Depending on updateable or non updateable cursors, blocked reads or fetch
may be performed. For insert statements blocked reads will automatically
performed.
                          
Birgitta

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von James H H Lampert
Gesendet: Freitag, 11. November 2005 21:01
An: Midrange Systems Technical Discussion
Betreff: Re: SQL newbie question

Okay. I've now got as far as pouring a single result set 
from a single programmatically-generated select into a 
file of the desired format, with this statement:

INSERT INTO QTEMP/WTGRPW  (GCID2) SELECT CID FROM
WTCONT CO  WHERE CO.U01010 = '1' WITH NC

and it seems to produce the desired results. It took a lot 
of futzing around to find that I needed the "WITH NC" to 
keep it from looking for a journal (dammit, who needs 
journaling or commitment control on a temporary file?!?!) 
and bombing.

In one of my experiments, I tried a "FOR READ ONLY" clause 
on the SELECT, knowing that's supposed to speed up the 
"open" operation, and it bombed with a message to the 
effect that such clauses could not be used on embedded 
SELECTs.

Which brought to mind the question:
How else would I pour a result set into my file without 
having to do it one-record-at-a-time? Is there another way 
besides what I already have? The message also said 
something about UNIONs not being available (which is kind 
of important here!)

--
JHHL

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.