Andy Kent said:
> Given that we don't live in such Utopian conditions, what approach
> would give the best compromise?

Call me old fashioned, but this really sounds like a job for Captain ACE
(or 4GL) )

--

Bye now,
Obnoxio

"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

"I'm trying to see things your way, but I can't get my head up my ass"
- JCH

"Ogni uomo mi guarda come se fossi una testa di cazzo"
- Marco

You're so stupid, you think martial arts are paintings by a sheriff...

I went to the airport to check in and they asked what I did because I
looked like a terrorist. I said I was a comedian. They said, "Say
something funny then." I told them I had just graduated from flying
school.

-- Ahmed Ahmed
sending to informix-list

Ah. I forgot to mention, they don''t have 4GL or SQL.

I'd hoped there might be an UNLOAD ... EXECUTE PROCEDURE to dump the
purged rows, and do an in-place copy of the wanted rows within the
procedure, but such an option doesn't seem to exist.

Andy

create 2 tables keep_rows and purge_rows

write a stored procedure which will read the existing data and copy the
data into either keep_rows or purge_rows.

drop the existing table

rename keep rows

unload the purge ros and file them away







Andy Kent wrote:
> Ah. I forgot to mention, they don''t have 4GL or SQL.
>
> I'd hoped there might be an UNLOAD ... EXECUTE PROCEDURE to dump the
> purged rows, and do an in-place copy of the wanted rows within the
> procedure, but such an option doesn't seem to exist.
>
> Andy

That would be the obvious one, but it incurs a lot of i/o. The whole of
the existing table would need to be written to the two other tables and
then one of those would need to be unloaded. (The purge amounts to
about 50% of the table).

I was hoping to find some way of unloading the data directly from the
old table.

Andy

Andy Kent schrieb:
> That would be the obvious one, but it incurs a lot of i/o. The whole of
> the existing table would need to be written to the two other tables and
> then one of those would need to be unloaded. (The purge amounts to
> about 50% of the table).
>
> I was hoping to find some way of unloading the data directly from the
> old table.
>
> Andy
>

read the FM about table fragmentation
and detaching of fragments. This can/will
do your job & is pretty fast, once your table
is fragmented and when you have multicpus & some
memory to throw into the job and using PQDPRIORITY

dic_k
--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe

How would range-based fragments do the trick without needing to add a
column to the table to determine whether or not the row is to be kept?
The deletion rules are complex (and involve more than one column) so
to-keep fragmentation couldn't be achieved with the existing schema.
Andy