Re: [repost] DBD::CSV and csv_eol=anything
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jeff Zucker) wrote: > "Scott R. Godin" wrote: > > > > unable to set ;csv_eol=\015, but saving the file via bbedit to DOS > > instead of Macintosh, the code works?!? what the hell? > > AFAIK, > > 1. If you are on a MAC and have all MAC-formatted files, don't set > csv_eol at all, DBD::CSV should do the right thing. unfortunately this is not the case, as in CSV.pm there is the following line: $opts{'eol'} = $meta->{'eol'} || $dbh->{'csv_eol'} || "\015\012"; so, for a Mac file I need to set it explicitly. > 2. If you are on a MAC and have all DOS formatted files, set csv_eol to > \015\012. Since this is the default (see above) it isn't necessary. As long as the file has DOS linefeeds, setting to \015\012 or not setting this at all results in usable data access. > 3. If you are on a MAC and have mixed files > >a. convert them all to one format before processing (recommended) > >or > >b. for the files that you know are DOS formatted, set csv_eol to > \015\012 and > do not set it all for the MAC formatted files > > > All well and good, except that the file is generated by a whole suite of > > perl scripts > > So use the scripts to put a MAC eol in the file and forget about csv_eol > in the report generating scripts. Well the issue here is one of independance between Mac and Unix -- if the file is generated on the Mac, I should be able to set csv_eol to \015 and have DBI 'do the right thing', likewise with unix setting csv_eol to \012 now, if DBI is creating the table, all is well and good -- the present setup creates files with \015\012 and as long as you DO NOT set csv_eol, everything is fine. It's when you are creating the "database files" with other applications and expect it (DBI and DBD::CSV) to do what it says it's supposed to, that things go flooey. -- Scott R. Godin| e-mail : [EMAIL PROTECTED] Laughing Dragon Services |web : http://www.webdragon.net/
Re: [repost] DBD::CSV and csv_eol=anything
"Scott R. Godin" wrote: > > unable to set ;csv_eol=\015, but saving the file via bbedit to DOS > instead of Macintosh, the code works?!? what the hell? AFAIK, 1. If you are on a MAC and have all MAC-formatted files, don't set csv_eol at all, DBD::CSV should do the right thing. 2. If you are on a MAC and have all DOS formatted files, set csv_eol to \015\012. 3. If you are on a MAC and have mixed files a. convert them all to one format before processing (recommended) or b. for the files that you know are DOS formatted, set csv_eol to \015\012 and do not set it all for the MAC formatted files > All well and good, except that the file is generated by a whole suite of > perl scripts So use the scripts to put a MAC eol in the file and forget about csv_eol in the report generating scripts. -- Jeff
[repost] DBD::CSV and csv_eol=anything
the list mysteriously and completely disappeared for roughly 10 minutes, and I wasn't sure if my post was received or not. *head-scratching* -=- unable to set ;csv_eol=\015, but saving the file via bbedit to DOS instead of Macintosh, the code works?!? what the hell? setting csv_eol=\015 when file format is saved as Macintosh results in this error, searching for "test": DBD::CSV::st execute failed: Missing first row at Primus 8.5GB:Applications:MacPerl 5.6.1a4 ΓΌ:site_perl:DBD:CSV.pm line 157, line 1. o if fileformat is DOS and csv_eol=\015, it searches the file but finds 0 results o if fileformat is DOS and I SET csv_eol=\015\012 it FINDS THE 7 RESULTS PROPERLY O_o i.e. it's only confused SOMEtimes. Somewhere, it's assuming the file is a DOS file, even though I'm setting csv_eol properly, the question is WHERE? my $dbh = DBI->connect("dbi:CSV:f_dir=${dbi_connect_dir};csv_sep_char=\t;csv_eol=\0 15\012", '', '', { RaiseError => 2 }) or die "Can't connect to database: $DBI::errstr"; All well and good, except that the file is generated by a whole suite of perl scripts running under MacPerl 5.6.1a*, (a mysql table output by SQL embedded in an .asp page, formatted to an html table, parsed by HTML::Parser, and tested for integrity by script # 3) and is read for report-generation by something like 10 other scripts. I don't want to go back through all the scripts and change the input and output record separators unless I absolutely have to, considering one single csv_eol=\015 is supposed to solve the problem :) DBI 1.20 DBD::CSV 0.1027 SQL::Statement 0.1020 Text::CSV_XS 0.22 MacPerl 5.6.1a4 I can post the complete script and a smidge of sample data if you wish -- Scott R. Godin| e-mail : [EMAIL PROTECTED] Laughing Dragon Services |web : http://www.webdragon.net/