I´m querying an Excel Sheet from a .NET Application with an Jet driver.
Are there any ressources on SQL on Excel files covering:
Formats, DataTypes, DataConversions, Supported Statements ... ?
Thank you
The SQL syntax is the same as for the Access database engine (Jet, whatever) version 4.0 i.e. Access2000 through Access2003.
The way the driver/provider works out data types is a little odd and can be frustrating that you can't just specify what they should be (as you can e.g. for a text file using a schema.ini file). This article I wrote on the subject many moons ago still gets a lot of traffic, read the comments for advanced help.
Related
Okay guys, I've been having this problem for a few weeks now and I'm getting no-where with it. I have OpenOffice and regular Office softwares. Both produce flawed .csv files, or at least phpMyAdmin can't read neither of these. Yes, I've been trying to change server's settings of uploading, etc. I also tried to contact my web hosting service and they claimed that all the .csv files I've produced are flawed.
Anyway, I'm looking for a way to convert .xls table to SQL. Most of the softwares out there cost money that I don't have. Furthermore, I've seen PHP systems that do just that, so I know this is possible.
No need converted to. sql, you can import directly with phpmyadmin or using tools like navicat for mysql in phpmyadmin go to the option to import, find the file, select the file type (csv or csv loaddata), in part below defines the column separator (if you do not know which opens the file with notepad)
if a very large file using navicat.
Flawed is "defective"?. I assume you have problem with excel, maybe you have defined the same column separator for separating thousands or decimals, use openoffice to open the file
Does anyone know a software which converts .xlsx (Excel) to .mdb (MS Access). Freeware or otherwise.
I tried PDS (Trial Version) , but doesn't look like it works well.
Thanks!
MS Access. That is the right way to go. Or you can use http://www.zamzar.com/
Using ColdFusion 9.0.1, I need to export hundreds of thousands of database records to Excel XLSX or CSV (XLSX is preferred). This must be done on demand. So far I've tried using cfspreadsheet but it chokes when exporting more than a couple thousand rows in the XLSX format. However, exporting to XLS works fine (of course there is a ~65,000 row limit).
What are my options to export so many records? Theoretically the users could need to export as many as one million records. I'm also using SQL Server 2008 R2 -- is there a way to somehow export the records to a file there and then send the file through CF to the user? What options do I have? Thanks.
Since you are using SQL Server 2008, you could take advantage of SQL Server Reporting Services (SSRS) and create a report that can be called via web service (or HTTP GET/POST) by ColdFusion. SSRS has the capability to export reports as Excel as well. You'll need to read up on SSRS to make this work, but it's fairly easy to do.
As you've discovered, doing this with ColdFusion's <cfspreadsheet/> tag fails because it builds the entire document in memory, which leads to JVM OutOfMemory errors. What you need is something that buffers output to disk so you don't run out of memory. This suggests CSV, which is far easier to buffer. I imagine there are ways to do it with Excel as well, but I don't know them.
So two options for you:
use a Java library
use ColdFusion's fileOpen(), fileWrite(), fileClose() methods
I'll cover each in turn.
Java Libary
opencsv is my preference. This assumes of course you know how to setup a .jar on the ColdFusion classpath. If you do then it's a matter using its APIs to open a file and specify data for each line. It's really quite simple. Check its docs for examples.
ColdFusion Methods
Be forewarned there be dragons here.
If you are exporting numbers or strings that do not contain any double quotes or commas you can probably do this. If not, figuring out what to escape and how is why you use a library in the first place. Code is roughly as such:
<!--- query to get whatever data you're working with --->
<cfset csvFile = fileOpen(filePath, 'read')>
<cfloop query="yourQuery">
<cfset csvRow = ""><!--- construct a csv row here from the query row --->
<cfset fileWrite(csvFile, csvRow)>
</cfloop>
<cfset fileClose(csvFile)>
If the query data you're working with is also large you may be dealing with a nested loop to chunk it out.
Dustin, I had to investigate this myself, and as of this writing (Summer 2011), POI does a fine job of generating large files, but you have to use xlsx. The 3.8 beta source ships with an example named "BigGridDemo" which generates a 100K, 4-column workbook very quickly. I modified it to generate 300K, 125-column sheet, and it handled it in about 2 minutes. It created a 1.6 GB, 3.6-million-row workbook in a little over half an hour.
Granted, the code isn't the prettiest to look at, but it works. I suspect it'll pretty up a bit when ported to ColdFusion.
In my app, I'm downloading a spreadsheet from FTP, moving the data read from the spreadsheet to a DataTable, and, depending on certain conditions, emailing a new spreadsheet (one that contains certain rows from the 1st spreadsheet).
My problem is creating the spreadsheet that will be mailed. I can't seem to work out how to add the row from the DataTable (originally from the spreadsheet that was downloaded) into the spreadsheet that's going to be mailed.
DS.Tables(0).Rows.Add(ObjSheet.Range(workTable.Rows(i)) - 1)
Is what I've got at the moment, but it's not working. workTable is the DataTable where the rows from the spreadsheet were copied to. DS is the DataSet where I'm putting the rows from the specific selection.
I'm pretty sure I can simplify the flow of data by eliminating either the DataTable or the DataSet.
To eliminate any confusion, I'm using VB2005 - Wish I could use 2008 for this, LINQ simplifies so much...
SpreadsheetGear for .NET can help you do this.
See the live ASP.NET (C# & VB) "Excel to Datagrid" samples here. There are more samples - some of which might prove useful - here.
Disclaimer: I own SpreadsheetGear LLC
One of the answers may be to not program with office - if you can use the Office 2007 file formats (and given the existence of the Office Compatability pack there's no fundamental reason why you shouldn't although there may be issues within a specific environment) then you can use .NET code, System.IO.Packaging and the Open XML Format SDK 1.0 - that's .NET 3.0 which is just libraries and therefore useable from VS2005.
More pragmatically, don't be so keen (at least in the first instance) to do away with the intermediate steps - something I need to remind myself at regular intervals.
If you start with the following:
1) Load the data from the source
2) Process the data from the source
3) Write the result out to the destination
Then you'll be able to demonstrate at steps 1 and 2 that you have what you want, and step 3 becomes more manageable in that you're just trying to move known data from app to file.
Hmm, that's more "thoughts" than "answer" - but I hope it helps.
We have built an Excel 2003 template that asks the user to select an XML file which is then imported into an XML Map and used to populate a worksheet.
Unfortunately it turns out that the users have Excel Standard Edition, which does not include the XML import functionality - namely the Workbook.XmlImport function.
Users are able to open the XML file via File -> Open etc, however this opens it up as a new workbook.
Does anyone know of a way to get around this? How can we get the XML data to populate the XML Map when the users have Excel 2003 Standard Edition?
Quick workaround:
Let them select the file to open
open that file into a new workbook using vba,
copy the contents of the new worksheet (or read it all in to vba recordsets to parse)
paste it back into your active worksheet (maybe after you've done stuff to it in VBA)
close the xml worksheet, not saving any changes.
That would get around it, but it won't be quite as flexible. Depends how much you need to do with it.
Any help?
The best course may be to buy a used version of 2003 Professional. You can get one for about $50. If you have a ton of users, this obviously doesn't scale. If you have four users, this would be a $200 fix to your problem.
If you're on the verge of upgrading, you might accelerate that process and make sure the 2007 flavor has XML support. I want to say that all of 2007 has XML, but definitely investigate it before you take my word.
Option 3 involves a lot of time and code. You can write VBA to import and refresh XML (or CSV or something else). Obviously you'd have to weigh the cost of coding to finding and buying enough used licenses.