|  |  | 
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
Re: st: binary format type str question
Thanks so much for your help. I have no problems reading the test files. 
Also, I now realize the first byte in the files I am having trouble with 
is not 113 by 110. Is there a document that explains this format (and 
other non-113 Stata formats) or should I just give up?
--Mark.
William Gould, Stata wrote:
Mark Fisher <[email protected]> has more questions about reading, with 
an eye to translating, .dta files.
I've learned a bit more about the structure of the file in question.
I read the file (correctly, I think) right up to the point where the 
data start. Then, in order to do some deconstrubtion, I simply read 
*all* the remaining bytes in the file; there are only 1071 of them. 
Since there are 6 variables (with types 98, 136, 102, 105, 102, and 98) 
and 51 observations, I don't see how I can possibly account for all of 
them since this only allows for 21 bytes per observation.
Something is not adding up.  Later in his post, Mark asks, "Is it possible
this dta file was created in a nonstandard way?" 
The answer is conditionally no, the condition being that the first byte in the
file is 0x71.  That is an important condition.  In earlier file formats, types
were coded differently.  For instance, if the first byte is 0x70, then the
file is from Stata 8.0, and the format was a little different.  If the first
byte is 0x6f, then the file is from Stata/SE 7.0, and is different yet again.
Historically, the number has ranged from 0x66.
Mark also asks, "Are there other dta files available on the web that I can
experiment with?"
      Point your browser to http://www.stata-press.com/data/r9/
Datasets that are used in the various Stata manuals are there.
Anyway, here is how things are supposed to work:
The typlist Mark reported as 
		type   
	---------------
	var. 1    98   
        var. 2   136   
	var. 3   102   
	var. 4   105   
	var. 5   102   
	var. 6   98    
	---------------
From that, I can build the following table:
		type    meaning    length     offset
	---------------------------------------------
	var. 1    98    str98          98          0
        var. 2   136    str136        136         98
	var. 3   102    str102        102        234
	var. 4   105    str105        105        336
	var. 5   102    str102        102        441
	var. 6   98     str98          98        543
	---------------------------------------------
	sum                           641
The width of an observation (a.k.a. lrecl) is 641 bytes.  The approved 
method is to read the data an observation at a time, in 641 byte 
chunks.  
I will now use C jargon.  Let (unsigned char *) buf[] contain one observation.
You can then extract each variable using memcpy(), using the offsets and
lengths from the table above.  Once extracted, if numeric, and if bytes need
reordering, reorder them.  If string, add a binary 0 terminator in case one is
missing.
This should be easy to code, but you will have to build a table in your 
code to direct what needs to be done.
-- Bill
[email protected]
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/