Hi Harold,
if I were doing this on UV I would do the following (inelegant error
handling but its just an example :):
If 1234.jpg is in a UV type 19 file:
OPEN "SOURCEFILE" TO SFT ELSE STOP
ASSIGN 1 TO SYSTEM(1017) ;* UV Specific - disables conversion of
CRLF to @AM on reading which damages your binary data
READ JPG FROM SFT, "1234.jpg" ELSE STOP
OPEN "TARGETFILE" TO TFT ELSE STOP
* Choose one of the following options to encode your data before storing
* 1: Hex Conversion - exactly doubles the size of the file
TDAT = OCONV(JPG, "MX0C")
* 2: Base64 conversion - slower but more space (33% size increase).
ERRCDE = ENCODE("Base64", 1, JPG, 1, TDAT, 1)
WRITE TDAT ON TFT ELSE STOP
hth,
Craig
Oaks, Harold wrote:
Dave-
Of course, unidata may be different than universe in its file structure.
However, I would like to try what you do.
How do you do that hex conversion? What is the next step? For example,
I have 1234.jpg at unix level. What specifically do you do to get that
into your unidata file?
Harold
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Davis
Sent: Tuesday, August 21, 2007 10:59 AM
To: [email protected]
Subject: RE: [U2] Binary data corruption on copy
That "$" trick is probably specific to pi/open.
I normally convert this kind of file to hex before storing in unidata.
If there's a better way, I would like to know about it.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oaks, Harold
Sent: Tuesday, August 21, 2007 1:10 PM
To: [email protected]
Subject: [U2] Binary data corruption on copy
A question for the group:
I have JPG format records which I wish to copy from unix level into a
Universe file but am having trouble with it getting 'corrupted' during
the copy. We are converting from pi/open to universe.
I can do this business in pi/open by changing the name of the source
file, prepending it with a $, then copying at TCL level into the pi/open
file. For example, if the record at unix level is named 1234.jpg and is
in the directory SOURCE I run this command at unix level:
mv 1234.jpg \$1234.jpg
which changes the name. Now at TCL level in pi/open I can issue the
command COPY FROM SOURCE TO IMAGE_FILE $1234.jpg After that, I can
change the name back within the pi/open file:
CNAME IMAGE_FILE $1234.jpg 1234.jpg
and the copy is complete.
Pi/open knows that if the record name starts with a dollar sign that it
is binary and should not be changed. Once the copy from a unix
directory into the pi/open dynamic file is done I can use it
successfully.
In Universe I attempt to do the same thing. The 1234.jpg name is
changed to $1234.jpg and then copied into the Universe file
UNIV_IMAGE_FILE, a dynamic (type 30) file.
But it doesn't work very well - the image is corrupted, the binary file
was messed with during the copy.
I know the jpg record is intact before I start the copying. I wouldn't
need to bother with a copy to a Universe file, in fact, except that we
have over 130,000 images now and I can't believe a unix directory could
successfully handle that many records.
Any suggestions on copying so that the binary remains intact?
Thanks-
Harold
Harold D. Oaks
Sr. Analyst/Programmer
Office of the Budget and Information Systems Clark County, Washington
ph: (360) 397-6121 x4132
fax: (360) 397-2342
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
--
Craig Bennett
Director
Amajuba Pty Ltd
Phone: 02 9987 0161
Mobile: 0412448781
Fax: 02 8456 5943
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
