Hi I am trying convert an xlsx and xlsm file to csvs using perl.
I have been using xls2csv but this doesnt work .
cannot read ampster1.xlsm is the error I get .
xls2csv is part of the old Spreadsheet::ParseExcel distribution, which handles only .xls files but not the newer formats. Try the Spreadsheet::XLSX module.
Related
I have a problem with unzipping files. Usually I use a PowerShell script, that I run through SQL Server database (procedure) and it will unzip my files how I want them (database shouldn't be any issue).
Main part of script:
exec '"for %i in ("'+#path+'\*.zip") do "C:\Program Files\7-Zip\7z.exe" x "%i" -o"'+#to+'""'
But for once in a while there is a .zip file that if run through this script will extract files with names of files encoded badly and to prevent that I need to manually open every .zip file and click to extract in 7-zip GUI and that will returns names of files correctly.
This manual way of doing things very, very slow. Because it needs to be done on a server, God forbids if I am on VPN at home. So let's say I have 5 zip files (3 GB), it will take me hours to unzip. If I do it, through server it takes like 2 minutes.
So I just trying to find out how to unzip it with script, what is the difference between my script and manual extraction?
The root-cause is likely to be files that were created with a setup that doesn't match the codepage of your windows environment. Are any of the zip file publicly available? If so, can you provide a link?
To deal with these problem files, you need to know what encoding was used for the filenames. If the 7z gui can handle these files automatically there must be an option to tell it what encoding to use.
Once you know the encoding you can use the -scs option in 7z to decode the filenames correctly.
Modern zip files don't have this issue because they store filenames in UTF-8.
I am starting to learn about databases and I have seen in the documentation (https://www.postgresql.org/docs/current/app-pgdump.html) that I can have an output of the pg_dump in either script or archive file format.
My question is, why would I choose an archive over a script format and another way around?
Is it only about the fact, that with archive files I can choose which part of the database should be restored with pg_restore? And if archive format seems to be more flexible than script format why would I ever choose to use script files instead?
I have set my Matlab (R2019b Update 9) to save Mat files in version 7 because I have a Python script that uses the scipy.io module to load mat files and v7.3 format is not supported by this Python module.
Manually saved mat files from Matlab workspace variables are created in format v7, however mat files created from Simulink ToFile blocks seem not to use that format as when I run my script on such mat files I encounter the error below:
NotImplementedError: Please use HDF reader for matlab v7.3 files
How to enforce ToFile blocks to use v7 format?
I would like to ask a question that is there a possibility to read and write .xlsx files in matlab 2008 on a computer which does not have installed Microsoft Excel. I would like to that is there any openxml kind of solution available for matlab?
Take a look at BatchConv, it is based on OpenOffice and should be able to convert the XLSX to CSV or XLS. You can call it via MATLAB system command to automate the full process.
Alternatively you can use Apache POI, but if you try to use it keep in mind that your MATLAB 2008 is running an old JRE, it might be incompatible to the latest versions of Apache POI which are able to read xlsx. In case you need to update java to use Apache POI, refer to this article
My code generates an excel 2007 file (.xlsx) from a data structure.
I am using Excel::Writer::XLSX module to create the excel file and to populate the workbook.
Although the code is working fine with 32bit active perl, while opening the excel, Excel 2007 is throwing error "An attribute value must not contain '<'."
Although the same code when executed using 64bit active perl produces excel without any issue.
Any pointer to what might be the reason will help?
Although the same code when executed using 64bit active perl produces excel without any issue.
Based on the error I'd guess that you aren't using the same version of Excel::Writer::XLSX with the 32 and 64 bit ActivePerls.
At the level the warning occurs at the code is pure Perl so there is no binary or 32/64bit issue that would cause this.
I would suggest ensuring that you have updated to the latest version of Excel::Writer::XLSX and testing again.
Also, it looks like the ActiveState repos for Excel::Writer::XLSX are significantly behind CPAN so make sure you upgrade the module from source and not via PPM.
If the issue still occurs then reduce the program down to the smallest amount of working code that demonstrates it and submit a bug report.