Subject | External File Construction |
---|---|
Author | Epstein, Ed |
Post date | 2004-02-09T19:24Z |
After getting some advice here, I am trying to use tables that are
referencing external files. Through trial and error I have gained some
working knowledge on how to create the external files with my frontend. I
am still having some problems, with null values specifically. Since an
external table cannot be altered, I cannot just set it to null and see how
the database constructs the file.
Double Precisions, Integers, Small Integers, and Time stamps are all
represented with the appropriate number of bytes. These operate as fixed
length values. I still dont have an exact idea of how these values are
constructed properely, left-right, right-left, signed, etc. I will try to
find an algorithm for constructing timestamp values.
Text fields can use the Char(X) specification, but would require padding
values and be very inefficient on disk usage and external file creation.
Interestingly enough, you can use VarChar for a field specification.
However, it operates with unexpected results. 2 bytes must precede the
actual field value. You would think these 2 bytes indicate how many bytes
to use as the field data, but it does not work that way. The number
indicated in the file specifications overrides this. So although a Varchar
value can be used, its still operating as a fixed length field and STILL
requires padding of values at the end. The 2 bytes are effectively useless.
I tested this by creating a file with 3 fields. 10,2, and 6 character field
lengths for each field per row. All field values had hex values of 000A,
0002, or a 0006 as the 2 bytes preceding the field value itself. The file
specifications where (A VarChar(10),B VarChar(2),C VarChar(6));. These
specifications worked perfectly. However, when ...(A VarChar(15),... was
used, it would then grab B's 2 byte length values as well as B itself and
would then screw up the rest of the file. If 0000 were used as a byte
length value (my thoughts on how to indicate null), it actually stopped
processing of the entire file itself as if EOF had been reached.
I am now completely lost on how to properly represent a null value in an
external file if now even possible at all. Also, a null value inside of a
number is an interesting question since those values do not have bytes in
front of them to represent their length and 00 00 00 00 would represent 0 as
an integer which is still a value.
If anybody has detailed knowledge on external files, their creation, and
corresponding file specifications i would be very gratefull.
Edwin Epstein
privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient, or an employee
or agent responsible for delivering this message
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer.
referencing external files. Through trial and error I have gained some
working knowledge on how to create the external files with my frontend. I
am still having some problems, with null values specifically. Since an
external table cannot be altered, I cannot just set it to null and see how
the database constructs the file.
Double Precisions, Integers, Small Integers, and Time stamps are all
represented with the appropriate number of bytes. These operate as fixed
length values. I still dont have an exact idea of how these values are
constructed properely, left-right, right-left, signed, etc. I will try to
find an algorithm for constructing timestamp values.
Text fields can use the Char(X) specification, but would require padding
values and be very inefficient on disk usage and external file creation.
Interestingly enough, you can use VarChar for a field specification.
However, it operates with unexpected results. 2 bytes must precede the
actual field value. You would think these 2 bytes indicate how many bytes
to use as the field data, but it does not work that way. The number
indicated in the file specifications overrides this. So although a Varchar
value can be used, its still operating as a fixed length field and STILL
requires padding of values at the end. The 2 bytes are effectively useless.
I tested this by creating a file with 3 fields. 10,2, and 6 character field
lengths for each field per row. All field values had hex values of 000A,
0002, or a 0006 as the 2 bytes preceding the field value itself. The file
specifications where (A VarChar(10),B VarChar(2),C VarChar(6));. These
specifications worked perfectly. However, when ...(A VarChar(15),... was
used, it would then grab B's 2 byte length values as well as B itself and
would then screw up the rest of the file. If 0000 were used as a byte
length value (my thoughts on how to indicate null), it actually stopped
processing of the entire file itself as if EOF had been reached.
I am now completely lost on how to properly represent a null value in an
external file if now even possible at all. Also, a null value inside of a
number is an interesting question since those values do not have bytes in
front of them to represent their length and 00 00 00 00 would represent 0 as
an integer which is still a value.
If anybody has detailed knowledge on external files, their creation, and
corresponding file specifications i would be very gratefull.
Edwin Epstein
> Continuity Partners Inc.CONFIDENTIALITY NOTICE: The information contained in this message may be
> 2753 S. Highland Dr.
> Suite 1010
> Las Vegas, Nevada 89109
> (702) 851-7850 Ext. 247
> eepstein@...
>
privileged and confidential and protected from disclosure.
If the reader of this message is not the intended recipient, or an employee
or agent responsible for delivering this message
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer.