changing raw to standard tables
A DBA asked whether reorganising a table by creating a copy as a RAW table, inserting the data, dropping the original and altering the copy back to STANDARD was a sound approach, and whether switching table types has hidden pitfalls. Replies noted: check for HDR (raw tables aren't replicated), beware insufficient free space leaving fragmentation, and that tables can simply be created as RAW. Art Kagel suggested a simpler route: drop indexes/constraints, optionally set NEXT SIZE, ALTER TABLE ... TYPE(RAW), ALTER FRAGMENT ... INIT IN <dbspace>, then back to STANDARD and rebuild indexes, plus a level-0 backup. The poster then queried robustness if the ALTER fails mid-way; no further answer is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
I have recently discovered the feature RAW-tables.
I would like to use it for table reorganization.
Instead of doing an unload / load of the data I
would like to do the following to reorg table X :
create table X_RAW ;
alter table X_RAW type (raw) ;
insert into X_RAW select * from X ;rename / drop table X ;
alter table X_RAW type ( standard ) ;rename table X_RAW to X ;
Adding indices / constraints / synonyms afterwards.
create level-0 backup
Is that a good plan?
Is there anything I have missed about standard and raw
tables or can I alter the type as I like with
no hidden constraints (except backup/recovery) ?
Regards,
Andreas Kutsche
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich
geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse,
enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
Informationen in dieser E-Mail sind ausschließlich für den Adressaten
bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir
Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung
zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter
fremdem Namen erstellt werden. Daher schließen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich
bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl.
hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.
Important notice: The contents of this e-mail may contain confidential and
legally protected information that is in particular related to operational and
trade secrets, which the recipient is obliged to treat as confidential. The
information in this e-mail is made available exclusively for use by the
addressee. In the event that the e-mail may have been sent to you in error, we
would ask you to kindly delete this communication from your system and to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out under
someone else's name. We therefore do not accept legal liability for the
information contained in this communication. The contents of the e-mail are
only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have
penetrated your system through the sending of this e-mail, we do not accept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
Are you running HDR ?
IBM Deutschland GmbH / Chairman of the Supervisory Board: Hans Ulrich
Maerki
Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michae=
l
Diemer
Corporate Seat: Stuttgart / Reg.-Gericht: Amtsgericht Stuttgart, HRB 14=
562
/ WEEE-Reg.-Nr. DE 99369940
=
"Andreas.KUTSCHE@ =
spar.at" =
<andreas.kutsche@ =
To
spar.at> ids@iiug.org =
Sent by: =
cc
ids-bounces@iiug. =
org Subj=
ect
changing raw to standard tables =
[9974] =
20.09.2007 17:59 =
=
=
Please respond to =
ids@iiug.org =
=
=
Hi,
I have recently discovered the feature RAW-tables.
I would like to use it for table reorganization.
Instead of doing an unload / load of the data I
would like to do the following to reorg table X :
create table X_RAW ;
alter table X_RAW type (raw) ;
insert into X_RAW select * from X ;rename / drop table X ;
alter table X_RAW type ( standard ) ;rename table X_RAW to X ;
Adding indices / constraints / synonyms afterwards.
create level-0 backup
Is that a good plan?
Is there anything I have missed about standard and raw
tables or can I alter the type as I like with
no hidden constraints (except backup/recovery) ?
Regards,
Andreas Kutsche
-------------------------------------------
SPAR =D6sterreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und recht=
lich
gesch=FCtzte Informationen, insbesondere Betriebs- oder Gesch=E4ftsgehe=
imnisse,
enthalten, zu deren Geheimhaltung der Empf=E4nger verpflichtet ist. Die=
Informationen in dieser E-Mail sind ausschlie=DFlich f=FCr den Adressat=
en
bestimmt. Sollten Sie die E-Mail irrt=FCmlich erhalten haben so ersuche=
n wir
Sie, die Nachricht von Ihrem System zu l=F6schen und sich mit uns in
Verbindung
zu setzen.
=DCber das Internet versandte E-Mails k=F6nnen leicht manipuliert oder =
unter
fremdem Namen erstellt werden. Daher schlie=DFen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. =
Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlic=
h
best=E4tigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die
Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht f=FCr =
evtl.
hieraus entstehende Sch=E4den.
Wir danken f=FCr Ihr Verst=E4ndnis.
Important notice: The contents of this e-mail may contain confidential =
and
legally protected information that is in particular related to operatio=
nal
and
trade secrets, which the recipient is obliged to treat as confidential.=
The
information in this e-mail is made available exclusively for use by the=
addressee. In the event that the e-mail may have been sent to you in er=
ror,
we
would ask you to kindly delete this communication from your system and =
to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out und=
er
someone else's name. We therefore do not accept legal liability for the=
information contained in this communication. The contents of the e-mail=
are
only legally binding if they have been confirmed and signed by us in
writing.
If, in spite of our using Antivirus protection software, a virus may ha=
ve
penetrated your system through the sending of this e-mail, we do not ac=
cept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
***********************************************************************=
********
Forum Note: Use "Reply" to post a response in the discussion forum.
=
Andreas,
It depends on how much the dbspace is fragmented, if you don't have enough
free space to create the extent, you can remanind with the same problem
(fragmented table) after maintenance.
Celso Cabral Coimbra
Administrador de Banco de Dados
ccoimbra@cleartech.com.br <mailto:ccoimbra@cleartech.com.br>
Fone: (11) 3576 4509 - Fax: (11) 3576 4515
www.cleartech.com.br <http://www.cleartech.com.br/>;
-----Mensagem original-----
De: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org]Em nome de
Andreas.KUTSCHE@spar.at
Enviada em: quinta-feira, 20 de setembro de 2007 13:00
Para: ids@iiug.org
Assunto: changing raw to standard tables [9974]
Hi,
I have recently discovered the feature RAW-tables.
I would like to use it for table reorganization.
Instead of doing an unload / load of the data I
would like to do the following to reorg table X :
create table X_RAW ;
alter table X_RAW type (raw) ;
insert into X_RAW select * from X ;rename / drop table X ;
alter table X_RAW type ( standard ) ;rename table X_RAW to X ;
Adding indices / constraints / synonyms afterwards.
create level-0 backup
Is that a good plan?
Is there anything I have missed about standard and raw
tables or can I alter the type as I like with
no hidden constraints (except backup/recovery) ?
Regards,
Andreas Kutsche
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich
geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse,
enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
Informationen in dieser E-Mail sind ausschließlich für den Adressaten
bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir
Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung
zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter
fremdem Namen erstellt werden. Daher schließen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich
bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl.
hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.
Important notice: The contents of this e-mail may contain confidential and
legally protected information that is in particular related to operational and
trade secrets, which the recipient is obliged to treat as confidential. The
information in this e-mail is made available exclusively for use by the
addressee. In the event that the e-mail may have been sent to you in error, we
would ask you to kindly delete this communication from your system and to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out under
someone else's name. We therefore do not accept legal liability for the
information contained in this communication. The contents of the e-mail are
only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have
penetrated your system through the sending of this e-mail, we do not accept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Maybe this was intentional, but you don't have to create the tables and then
alter them to raw. They can be created as raw tables.
create raw table foo ...... works fine.
I used a similar method to build/rebuild data warehouse tables that were
restated nightly.
HTH,
-D
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Andreas.KUTSCHE@spar.at
Sent: Thursday, September 20, 2007 12:00 PM
To: ids@iiug.org
Subject: changing raw to standard tables [9974]
Hi,
I have recently discovered the feature RAW-tables.
I would like to use it for table reorganization.
Instead of doing an unload / load of the data I
would like to do the following to reorg table X :
create table X_RAW ;
alter table X_RAW type (raw) ;
insert into X_RAW select * from X ;rename / drop table X ;
alter table X_RAW type ( standard ) ;rename table X_RAW to X ;
Adding indices / constraints / synonyms afterwards.
create level-0 backup
Is that a good plan?
Is there anything I have missed about standard and raw
tables or can I alter the type as I like with
no hidden constraints (except backup/recovery) ?
Regards,
Andreas Kutsche
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich
geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse,
enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
Informationen in dieser E-Mail sind ausschließlich für den Adressaten
bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir
Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung
zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter
fremdem Namen erstellt werden. Daher schließen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich
bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl.
hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.
Important notice: The contents of this e-mail may contain confidential and
legally protected information that is in particular related to operational and
trade secrets, which the recipient is obliged to treat as confidential. The
information in this e-mail is made available exclusively for use by the
addressee. In the event that the e-mail may have been sent to you in error, we
would ask you to kindly delete this communication from your system and to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out under
someone else's name. We therefore do not accept legal liability for the
information contained in this communication. The contents of the e-mail are
only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have
penetrated your system through the sending of this e-mail, we do not accept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
________________________________________________________________________________
_____
The information contained in this email may be confidential and/or legally
privileged. It has been sent for the sole use of the intended recipient(s). If
the reader of this message is not an intended recipient, you are hereby
notified that any unauthorized review, use, disclosure, dissemination,
distribution, or copying of this communication, or any of its contents, is
strictly prohibited. If you have received this communication in error, please
contact the sender by reply email and destroy all copies of the original
message. To contact our email administrator directly, send to
postmaster@dlapiper.com
Thank you.
________________________________________________________________________________
_____
Better (simpler and possibly faster) plan:
0- ALTER TABLE mytable NEXT SIZE <value>; -- Optional. <value> should be large
enough to hold a typically active set of rows so that at most
two extents need to be accessed for any common query.
1- drop constraints and indexes
2- ALTER TABLE mytable type ( RAW );
3- ALTER FRAGMENT ON TABLE mytable INIT IN somedbspace_or_fragments_expr;
4- ALTER TABLE mytable type ( STANDARD );
5- recreate indexes and constraints.
The 'IN ... ' clause can contain the same dbspace or fragmentation expression
currently supporting the table of a different one.
Art S. Kagel
----- Original Message -----
From: Andreas.KUTSCHE@spar.at <ids@iiug.org>
To: ids@iiug.org
At: 9/20 12:00:19
Hi,
I have recently discovered the feature RAW-tables.
I would like to use it for table reorganization.
Instead of doing an unload / load of the data I
would like to do the following to reorg table X :
create table X_RAW ;
alter table X_RAW type (raw) ;
insert into X_RAW select * from X ;rename / drop table X ;
alter table X_RAW type ( standard ) ;rename table X_RAW to X ;
Adding indices / constraints / synonyms afterwards.
create level-0 backup
Is that a good plan?
Is there anything I have missed about standard and raw
tables or can I alter the type as I like with
no hidden constraints (except backup/recovery) ?
Regards,
Andreas Kutsche
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich
geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse,
enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
Informationen in dieser E-Mail sind ausschließlich für den Adressaten
bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir
Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung
zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter
fremdem Namen erstellt werden. Daher schließen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich
bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl.
hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.
Important notice: The contents of this e-mail may contain confidential and
legally protected information that is in particular related to operational and
trade secrets, which the recipient is obliged to treat as confidential. The
information in this e-mail is made available exclusively for use by the
addressee. In the event that the e-mail may have been sent to you in error, we
would ask you to kindly delete this communication from your system and to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out under
someone else's name. We therefore do not accept legal liability for the
information contained in this communication. The contents of the e-mail are
only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have
penetrated your system through the sending of this e-mail, we do not accept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
Hello,
yes, the ALTER FRAGMENT is obviously simpler than
CREATE-new/INSERT/DROP-old/RENAME,
but what happens if something is going wrong when the ALTER TABLE is running
(server
crash, session gets terminated , connection lost , ...) ?
Is the copying to a new table and renaming it more robust, isn't it? Sure it's
more
complicated and needs more care about depending objects (views, synonyms).
But generally, if there is
- enough space to contain the old and new version of a table
(either by copying or alter fragment)
- no DML on a table (e.g. application is stopped)
- a level-0 archive takes less time than the table reorganization(s)
in that case is the use temporary use of the RAW-type the best way
to reorganize a table?
Or would you recommend another method (e.g. SAP turns off logging for the
WHOLE database and does the CREATE/INSERT/DROP/RENAME stuff)?
Regards,
Andreas Kutsche
>
-------------------------------------------
SPAR Österreichische Warenhandels-AG
Hauptzentrale
A - 5015 Salzburg, Europastrasse 3
FN 34170 a
Tel: +43 662 4470 24223
Mobile: +43 664 6259575
E-Mail: Andreas.KUTSCHE@spar.at
Internet: http://www.spar.at
Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche und rechtlich
geschützte Informationen, insbesondere Betriebs- oder Geschäftsgeheimnisse,
enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
Informationen in dieser E-Mail sind ausschließlich für den Adressaten
bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so ersuchen wir
Sie, die Nachricht von Ihrem System zu löschen und sich mit uns in Verbindung
zu setzen.
Über das Internet versandte E-Mails können leicht manipuliert oder unter
fremdem Namen erstellt werden. Daher schließen wir die rechtliche
Verbindlichkeit der in dieser Nachricht enthaltenen Informationen aus. Der
Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns schriftlich
bestätigt und gezeichnet wird.
Sollte trotz der von uns verwendeten Virus-Schutzprogramme durch die Zusendung
von E-Mails ein Virus in Ihre Systeme gelangen, haften wir nicht für evtl.
hieraus entstehende Schäden.
Wir danken für Ihr Verständnis.
Important notice: The contents of this e-mail may contain confidential and
legally protected information that is in particular related to operational and
trade secrets, which the recipient is obliged to treat as confidential. The
information in this e-mail is made available exclusively for use by the
addressee. In the event that the e-mail may have been sent to you in error, we
would ask you to kindly delete this communication from your system and to
contact us.
E-mails sent via the Internet can be easily manipulated or sent out under
someone else's name. We therefore do not accept legal liability for the
information contained in this communication. The contents of the e-mail are
only legally binding if they have been confirmed and signed by us in writing.
If, in spite of our using Antivirus protection software, a virus may have
penetrated your system through the sending of this e-mail, we do not accept
liability for any damage that may possibly arise as a result of this.
We trust that you appreciate our position.
-------------------------------------------
-----Ursprüngliche Nachricht-----
> Von: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org]Im Auftrag von
> ART KAGEL, BLOOMBERG/ 731 LEXIN
> Gesendet: Donnerstag, 20. September 2007 18:27
> An: ids@iiug.org
> Betreff: Re:changing raw to standard tables [9978]
>
>
> Better (simpler and possibly faster) plan:
>
> 0- ALTER TABLE mytable NEXT SIZE <value>; -- Optional.
> <value> should be large
>
> enough to hold a typically active set of rows so that at most
>
> two extents need to be accessed for any common query.
> 1- drop constraints and indexes
> 2- ALTER TABLE mytable type ( RAW );
> 3- ALTER FRAGMENT ON TABLE mytable INIT IN
> somedbspace_or_fragments_expr;
> 4- ALTER TABLE mytable type ( STANDARD );
> 5- recreate indexes and constraints.
>
> The 'IN ... ' clause can contain the same dbspace or
> fragmentation expression
> currently supporting the table of a different one.
>
> Art S. Kagel
>
> ----- Original Message -----
> From: Andreas.KUTSCHE@spar.at <ids@iiug.org>
> To: ids@iiug.org
> At: 9/20 12:00:19
>
> Hi,
>
> I have recently discovered the feature RAW-tables.
> I would like to use it for table reorganization.
>
> Instead of doing an unload / load of the data I
> would like to do the following to reorg table X :
> create table X_RAW ;
> alter table X_RAW type (raw) ;
> insert into X_RAW select * from X ;> rename / drop table X ;
> alter table X_RAW type ( standard ) ;> rename table X_RAW to X ;
> Adding indices / constraints / synonyms afterwards.
> create level-0 backup
>
> Is that a good plan?
> Is there anything I have missed about standard and raw
> tables or can I alter the type as I like with
> no hidden constraints (except backup/recovery) ?
>
> Regards,
> Andreas Kutsche
> -------------------------------------------
> SPAR Österreichische Warenhandels-AG
> Hauptzentrale
> A - 5015 Salzburg, Europastrasse 3
> FN 34170 a
>
> Tel: +43 662 4470 24223
> Mobile: +43 664 6259575
> E-Mail: Andreas.KUTSCHE@spar.at
> Internet: http://www.spar.at
>
> Wichtiger Hinweis: Der Inhalt dieser E-Mail kann vertrauliche
> und rechtlich
> geschützte Informationen, insbesondere Betriebs- oder
> Geschäftsgeheimnisse,
> enthalten, zu deren Geheimhaltung der Empfänger verpflichtet ist. Die
> Informationen in dieser E-Mail sind ausschließlich für den Adressaten
> bestimmt. Sollten Sie die E-Mail irrtümlich erhalten haben so
> ersuchen wir
> Sie, die Nachricht von Ihrem System zu löschen und sich mit
> uns in Verbindung
> zu setzen.
> Über das Internet versandte E-Mails können leicht manipuliert
> oder unter
> fremdem Namen erstellt werden. Daher schließen wir die rechtliche
> Verbindlichkeit der in dieser Nachricht enthaltenen
> Informationen aus. Der
> Inhalt der E-Mail ist nur rechtsverbindlich, wenn er von uns
> schriftlich
> bestätigt und gezeichnet wird.
> Sollte trotz der von uns verwendeten Virus-Schutzprogramme
> durch die Zusendung
> von E-Mails ein Virus in Ihre Systeme gelangen, haften wir
> nicht für evtl.
> hieraus entstehende Schäden.
> Wir danken für Ihr Verständnis.
>
> Important notice: The contents of this e-mail may contain
> confidential and
> legally protected information that is in particular related
> to operational and
> trade secrets, which the recipient is obliged to treat as
> confidential. The
> information in this e-mail is made available exclusively for
> use by the
> addressee. In the event that the e-mail may have been sent to
> you in error, we
> would ask you to kindly delete this communication from your
> system and to
> contact us.
> E-mails sent via the Internet can be easily manipulated or
> sent out under
> someone else's name. We therefore do not accept legal
> liability for the
> information contained in this communication. The contents of
> the e-mail are@@NL