|
On Fri, Feb 18, 2000 at 11:58:47PM -0500, Sean Porterfield wrote: > > > Next, I wonder how useful is the buffer lengh on a packed field? We're > > > converting to integers which means the length of our data isn't going to > > > be the buffer length. If it's a 'P' field, shouldn't we use the field > > > length instead? > > > > The conversion should work fine: so far as I understand, the mathematical > > relationship between field size and representation length always holds, > > so why bother parsing another field? > > Maybe I don't know what to look for, but in the XML I get > TYPE="P" OFFSET="26" WIDTH="4" PRECISION="0" on a field that is define as > 6,0 on the 400. I was hoping I could use the WIDTH="" to know how to > create my database fields. This little snippet of pseudo-code will determine the length you want: store width attribute to "length" variable if "type" attribute is "P" then store (width * 2) - 1 to "length" variable end if // Length variable now contains display length (less decimal point if one is // required You'll notice that this would make the length 7 and not 6 - the resulting length from this formula would always be odd, and therefore possibly one greater than the actual database field. I just realized this, so I'm filing in my todo to store a LENGTH= attribute in the file. > > > > Finally, (off topic a bit) any easy way to define an SQL field type > > > based on the buffer length or field length? I have a lot of files with > > > a lot of fields, so it would be a nightmare to create all the tables > > > manually. I tried dds2sql on the DDS of the file, but that was a > > > disaster. > > > > I'm confused. You're trying to asdbget |asdb2tab | ???? Are you trying > > to use as4002unix? Where are you trying to get this data to? > > I'm trying to make it harder than it should be, of course. My goal here > is to replicate a bunch of database files from the AS/400 in MySQL. I > need to create the MySQL tables, though, so I need valid CREATE TABLE SQL > statements that match my data. After that, I'll just load from tab files > (unless I decide to check the data format first, which might be a good > idea.) Blah. Just hack the asdb2tab file. You should really only have to change the 'print' statements to generate SQL, both the CREATE TABLE and the INSERT INTO statements could be generated in one pass. If the table is already there, then the CREATE TABLE statement just fails. Simple 'nuff. Maybe I'll provide an asdb2pg script in the next release. (BTW, I highly recommend PostgreSQL. Last I heard, MySQL was missing all sorts of features including transactions and sorts of cascading queries. And PostgreSQL recently closed most of the gap in performance and the most recent version is Open Source). -Jay 'Eraserhead' Felice +--- | This is the LINUX5250 Mailing List! | To submit a new message, send your mail to LINUX5250@midrange.com. | To subscribe to this list send email to LINUX5250-SUB@midrange.com. | To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.