NX: db.db file format

[S. Ganapathy]

In the instructions for data file format for end of file,
Start of file
4 byte numeric - magic cookie
4 byte numeric - length of the record
2 byte numeric - number of fields in each record
Schema Description
2 byte numeric - length in bytes of field name
n bytes - field name
2 bytes numeric - field length in bytes
repeat the above for every field in the record
Data Section
1 byte delete flag - 0 valid record, 1 deleted record
Record contains fields in the order specified, no seperators bet fields, each field is fixed length at maximum specified in schema information
End of file
All numeric values are stored in the header information use the formats of the DataInputStream and DataOutputStream classes. All text values, and fields(which are text only), contain only 8 bit chatacters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII.

I used the command "C:\>more db.db > out"
All the data is found in a formatted form(like tabular form).
I tried to add record which is specified in the format, I am facing some probelms if i use the same command to format. But it i found those records, I added to the db file, are getting displayed in the same line. I don't know the reason for that. Please help me how to write the data in db file.
Thaks in advance
Ganapathy
[ April 18, 2003: Message edited by: Ganapathy]
[ April 29, 2003: Message edited by: Ganapathy S ]

[frank sun]

You can use the class java.io.RandomAccessFile to read/write the file, it's not helpful to use the command 'more ' to display the file content.
Please refer to the RandomAccessFile document.
Frank.

[Ta Ri Ki Sun]

I'd love to help you but you'll have to be more specific than that, as a rule of thumb tho dont believe what the more command tells you, in this case it says theres a tabular format, it is definately not, not if you read it one byte at a time, theres absolutely no newline escape sequence which is what more might imply from a visual point of view, rather open a stream and read your bytes just as Sun said they will appear in that document you quoted, every byte is exactly where they said it would be.

[S. Ganapathy]

All text values, and fields(which are text only), contain only 8 bit chatacters,
null terminated if less than the maximum length for the field.
The character encoding is 8 bit US ASCII.
I could not get what "null terminated if less than the maximum length for the field" means.
[ April 18, 2003: Message edited by: Ganapathy, S]
[ April 29, 2003: Message edited by: Ganapathy S ]

[Ta Ri Ki Sun]

Originally posted by Venkateswara Rao Gunturu:
All text values, and fields(which are text only), contain only 8 bit chatacters,
null terminated if less than the maximum length for the field.
The character encoding is 8 bit US ASCII.
I could not get what "null terminated if less than the maximum length for the field" means.
[ April 18, 2003: Message edited by: Venkateswara Rao Gunturu ]

that 8 bit US ASCII is misleading, because according to java.sun.com

US-ASCII

US-ASCII is a 7-bit encoding scheme that covers the English-language alphabet. It is not large enough to cover the characters used in other languages, however, so it is not very useful for internationalization.

Java Encoding Schemes
it is in fact 7 bit.
and about the null terminated, unless Sun means char(' ') is a null there is no such termination, so dont worry about it at all, just read the max length the record should be, and either ignore the character where relevant or treat it as any other character

[S. Ganapathy]

Thankyou very much Ta Ri Ki Sun
Ganapathy
[ April 29, 2003: Message edited by: Ganapathy S ]

[Barry Gaunt]

The null character is C char 0 (a byte containing all zero bits). It is used by C/C++ programs, for instance, to terminate a string in an array of char. Now, Sun says the file has to be usable by a legacy application, and this is the first Java application, right? So you could in theory get a field of width 24 containing the bytes 'H', 'e', 'l', 'l', 'o', 0, the rest being junk. According to the assignment instuctions I have, the Java application must be able to import this data.
[ April 25, 2003: Message edited by: Barry Gaunt ]

[Ta Ri Ki Sun]

Originally posted by Barry Gaunt:
The null character is C char 0 (a byte containing all zero bits). It is used by C/C++ programs, for instance, to terminate a string in an array of char. Now, Sun says the file has to be usable by a legacy application, and this is the first Java application, right? So you could in theory get a field of width 24 containing the bytes 'H', 'e', 'l', 'l', 'o', 0, the rest being junk. According to the assignment instuctions I have, the Java application must be able to import this data.
[ April 25, 2003: Message edited by: Barry Gaunt ]

the null character is char 0 but my fields all end in char 32 , which is space, and because of this I pad/justify any updates accordingly

[S. Ganapathy]

Hi Ta Ri Ki Sun, and Barry Gaunt,
In the assignment, they clearly mentioned in the

End of file section
All numeric values are stored in the header information use the formats of the DataInputStream and DataOutputStream classes. All text values, and all fields(which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII.

What I feel is java implementation of String also ends with char 0.
In my assignment, last field of the record is 8 digit number. That means it is text only. I am reading all the values of the record as Strings only. Initially I read the record in the byte array, and constructing String object, and then takingout the fields according to their field length.
Here I have a doubt. Whether I am right or going out of track. Please correct me. While creating new record, I am padding with empty spaces to fill the maximum field length.
Ganapathy
[ April 29, 2003: Message edited by: Ganapathy S ]

[Ta Ri Ki Sun]

Originally posted by Venkateswara Rao Gunturu:
Hi Ta Ri Ki Sun, and Barry Gaunt,
In the assignment, they clearly mentioned in the

What I feel is java implementation of String also ends with char 0.
In my assignment, last field of the record is 8 digit number. That means it is text only. I am reading all the values of the record as Strings only. Initially I read the record in the byte array, and constructing String object, and then takingout the fields according to their field length.
Here I have a doubt. Whether I am right or going out of track. Please correct me. While creating new record, I am padding with empty spaces to fill the maximum field length.
GVRao

if you dont pad it you dont have a FLT file anymore.
FLT means Fixed Length Text and thats what your DB file is, change the length and you'll either have to work around it or everything will go wrong, either way you cant pass, so stick to padding.

[Barry Gaunt]

What I feel is java implementation of String also ends with char 0.
No, the Java implementation of a String does not end in a 0. The length of a Java String is given by String.length(). In C you use int strlen( const char * ) and that searches from the first char until it finds 0. (If my memory serves me correctly.)
I look at it this way.
A. Output to file from Java:
Choice 1. Pad short string with blanks to whole field width.
Choice 2. Terminate short string with 0. The rest of the field does not have to overwritten.
B. Input to Java from file:
Read complete field width and check for 0. If 0 is found make a new String (or set StringBuffer length) so only the characters upto, but not including the 0, are used by the Java program.
Disclaimer: Don't forget, I'm not telling you guys what to do, this is just my current thinking on what I may do.
-Barry
[ April 25, 2003: Message edited by: Barry Gaunt ]

[Barry Gaunt]

Hi TQ, the characters FLT do not exist in my instructions.
The fields are fixed length. What I am talking about is the contents of the fields.
Say we have a 10 byte wide field. We can have.
'H', 'e', 'l', 'l', 'o', ' ', ' ', ' ', ' ', ' '
or we can have
'H', 'e', 'l', 'l', 'o', 0, '?', '*', '8', 'f'
for example.
[ April 25, 2003: Message edited by: Barry Gaunt ]
[ April 25, 2003: Message edited by: Barry Gaunt ]

[Ta Ri Ki Sun]

Barry are you saying they can use/test the 2 examples you posted interchangably?

EG 1
'H', 'e', 'l', 'l', 'o', ' ', ' ', ' ', ' ', ' '
or we can have
EG 2
'H', 'e', 'l', 'l', 'o', 0, '?', '*', '8', 'f'

when I read the instructions I expected to find example 2 , instead I found 1, now are you saying that we should cater for both?

[Barry Gaunt]

That's right TQ, in the sample db-2x2.db file the records are padded with blanks as your EG 1. But the instructions imply that they may not always be. So I will allow for the null terminated possibility EG 2.
Once again, my discaimer holds. I'm not in a hurry and will be thinking about things for another month or two before I start designing.

[Ta Ri Ki Sun]

Originally posted by Barry Gaunt:
That's right TQ, in the sample db-2x2.db file the records are padded with blanks as your EG 1. But the instructions imply that they may not always be. So I will allow for the null terminated possibility EG 2.
Once again, my discaimer holds. I'm not in a hurry and will be thinking about things for another month or two before I start designing.

I dont normally like people telling me I have more work but thanks for the heads up, I probably just have to add an extra line or 2, I'll double check later

[S. Ganapathy]

Hi,

Record containing fields in order specified in schema section, no seperators between fields, each field fixed at maximum length specified in schema information.

According to the above, what I feel about null terminated string is:
String nullString = "";
There is no data in it.
Also from the original String implementation, actual value of string is stored in a character array.
According to sun implementation of String,
public String() {
value = new char[0];
}
This is equivalent to nullStirng = "";, no character data in it.
There is no need to discuss about 0 terminated string as in case of C/C++
Ganapathy
[ April 29, 2003: Message edited by: Ganapathy S ]