software development

Getting the Sheet Name(s) from an Excel Document with OleDb

users name their sheets all sorts of crazy things, but sometimes, I want to be able to get the sheet names regardless of what they are named

Considering that I already have my ConnectionString strC set up to access my Excel file, I can just use the GetOleDbSchemaTable method like this:
DataTable dtS;
using (OleDbConnection c = new OleDbConnection(strC))
  dtS = c.GetOleDbSchemaTable(OleDbSchemaGuid.Tables, 
    new object[] { null, null, null, "TABLE" });

Now dtSchema holds the sheet names (in alphabetical order). To get them out:
foreach(DataRow row in dtS.Rows)

Automatically clean up/kill Orphaned Processes

A nice easy way to patrol and eliminate orphaned processes 

I have several web applications on our local intranet that require Excel to be called to make documents for my users.  That brings up a problem:If you add the impatient tendancies of users (hey, I just clicked that button, I want my spreadsheet NOW!) to the statelessness of html on top of the stubornnessof the Excel process you get orphans, those pesky orphans that sit around, use your resources and do nothing.  Now programatically, I have done all I can to kill these bastards but I can't seem to stop the persistant jerks 100% of the time.


So, what I decided to do was to make an 'enforcer' on the web server that makes his rounds every five minutes and kills any of these little pricks that are still hanging out in my otherwise peaceful system.  This enforcer is not only effective, he is also efficient (tiny script, executes instantly) and keeps track of his work (log file).


The code for my vbs file can be seen here:



Option Explicit
Dim objWMIService, objProcess, colProcess, intCount
Dim strComputer, strProcessKill, logPath
strComputer = "."
strProcessKill = "'EXCEL.EXE'" 'process to kill
logPath = "C:\scripts\killExcel.log" 'path to log file
intCount = 0

Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" _
& strComputer & "\root\cimv2")

Set colProcess = objWMIService.ExecQuery _
("Select * from Win32_Process Where Name = " & strProcessKill )
For Each objProcess in colProcess
intCount = intCount + 1

If intCount > 0 Then
    Dim fso, txtFile
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set txtFile = fso.OpenTextFile(logPath, 8)
    txtFile.WriteLine(Date & " - " & Time & " Killed " _
    & intCount & " processe(s)")
End If




As you can see, it's very simple, and you can change it to eliminate any kind of process you want.  Here it is if you want to check it out, included is an empty log file, the vbs file, and the bat file used to schedule it (assuming you place this in c:\scripts\), enjoy.



Translate an Excel Serial Date into a C# DateTime

An annoying little 'feature' of Excel is that it stores dates in a strange format

I stole the logic and from Code Project and wrote some code that will give you a DateTime variable if you feed it a Excel serial integer (number of days after 2/29/1900).  Strangely enough, DateTime.Parse("2/29/1900"); throws an error, so the simple solution I thought of: DateTime.Parse("2/29/1900").AddDays(excelInteger); does not work.  But this does:



public DateTime ExcelSerialDateToDT(int nSerialDate)
    int l = nSerialDate + 68569 + 2415019;
    int n = ((4 * l) / 146097);
    l = l - ((146097 * n + 3) / 4);
    int i = ((4000 * (l + 1)) / 1461001);
    l = l - ((1461 * i) / 4) + 31;
    int j = ((80 * l) / 2447);
    int nDay = l - ((2447 * j) / 80);
    l = (j / 11);
    int nMonth = j + 2 - (12 * l);
    int nYear = 100 * (n - 49) + i + l;

    return DateTime.Parse(nMonth + "/" + nDay + "/" + nYear);



As long as your date isn't within 60 days of 2/29/1900, this will work perfectly (don't ask why those are screwed up Tongue out).

Complete Web-Based Excel Spreadsheet Builder

Have your users make spreadsheets online, no excel needed

Now first off, this places a DataTable into the Session State, and I know some people have a problem with that... I don't care.  Now that that is out of the way, I can explain how this works.


It is very simple, this program runs through all of the TextBoxes and DropDownLists that you have within the input_container Panel and adds them as string columns to a DataTable dt.  Once that is done, each entry is simply added to the DataTable and rendered onto a GridView.  Then I use Matt Berseth's GridViewExportUtil to spit the spreadsheet out to the user.  Everything is taken care of real-time with no writing to the disk. Pretty simple.


I also included a way to edit as a normal method wouldn't work in this case, it just populates a DropDownList every time you add a new item and pops it back into the forms if you choose to edit it _but_ if you do not save, the record will be lost (there is a warning).


Another thing to note is that this is a drop-in-and-use application.  Everything is populated automatically, you need to do absolutely nothing to the code-behind in order to use this utility, just customize your fields in the default.aspx in the input_container and the rest of the work is done for you.  I used my method of parsing IDs of the input fields to make column names so ddlLets_Party turns in to a column "Lets Party", Last_Name becomes "Last Name", strFruit becomes "Fruit" and so on.   You could easily add another attribute as ColumnName or something like that if you please.


Here is the provided example: Excel Spreadsheet Builder In Action, and the code:

Appending a single Excel sheet to an existing Excel Spreadsheet programatically


This can be done via a web-interface via Excel Interop commands

I was asked to take some user input, produce an Excel spreadsheet, then append it to an exisiting workbook that had multiple static spreadsheets then spit the Excel sheet out as a download.  Excel Interop processes are not that easy to work with, and can be quite a pain.  After fumbling around, I was able to come up with a (possibly rudimentary) way to do this.


Now this is just a small part of a much larger program that takes in user input, and saves it to a temporary directory as an Excel spreadsheet.  Inside that directory there is also another file that doesn't change that thsi will be appended to, I call this my 'base' file.  The snippet I am providing combines the files and saves them as a seperate new file before my program sends it to the user.


There is likely a better way to do this without all of the saving with a stream, but I am not sure how and am wide open for better solutions!  Anyways, here is the function I ended up using.  The inputs are:

  • baseFile is the path to the static file I am appending to
  • newSheet is the path to the new file that I am appending to the base
  • newFile is the path to the final appended sheet 



protected void AppendSheet(string baseFile, string newSheet, string newFile)
        exc = new Microsoft.Office.Interop.Excel.Application();
        exc.Workbooks.Open(baseFile, Type.Missing, false, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
        exc.Workbooks[1].Sheets.Add(Type.Missing, exc.Workbooks[1].Sheets[1], 1, newSheet);
        if (System.IO.File.Exists(newFile)) System.IO.File.Delete(newFile);
        exc.Workbooks[1].SaveAs(newFile, Type.Missing, Type.Missing, Type.Missing, Type.Missing, false, Microsoft.Office.Interop.Excel.XlSaveAsAccessMode.xlNoChange, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing);
    catch (Exception ex)
        //handle your exception


Destroy those pesky orphaned Excel processes in .Net programs

If you have ever worked with Excel in the .Net environment, you likely have run across the occasional orphan and they can be a pain to clean up

Recently I was doing just this, and my Task Manager was filling up with orphans fast.  I was calling for the Excel Process to close, but that wasn't working most of the time.  So I came up with a more elaborate way to make them disappear.  Basically I found out that in order to close the application, you have to close the workbooks, and in order to close the workbooks, you have to close each workbook individually, and to close those, you have to close each worksheet in those workbooks individually.  I also included COM management, so we are hitting this with multiple attacks to make sure they stay dead!  So the super-overkill-do-everything process is:


  1. Collect each worksheet individually
  2. Collect each workbook individually
  3. Delete the worksheets
  4. Release the worksheets
  5. Null the worksheets
  6. Delete the workbooks
  7. Release the workbooks
  8. Null the workbooks
  9. Close the workbooks collection
  10. Quit the application
  11. Release the application
  12. Null the application
  13. Collect garbage


Here's how

After your work is done, you are left with a Microsoft.Office.Interop.Excel.Application named 'exc', call killExcel(exc):

protected void killExcel(Microsoft.Office.Interop.Excel.Application exc)
        List<Microsoft.Office.Interop.Excel.Workbook> wbs = new List<Microsoft.Office.Interop.Excel.Workbook>();
        List<Microsoft.Office.Interop.Excel.Worksheet> wss = new List<Microsoft.Office.Interop.Excel.Worksheet>();
        foreach (Microsoft.Office.Interop.Excel.Workbook wb in exc.Workbooks)
            foreach (Microsoft.Office.Interop.Excel.Worksheet ws in wb.Worksheets)
                wss.Add(ws); // collect worksheets
            wbs.Add(wb); // collect workbooks
        for (int i = 0; i < wss.Count; i++)
            System.Runtime.InteropServices.Marshal.ReleaseComObject(wss[i]); // release it
            wss[i] = null; // null it
        for (int i = 0; i < wbs.Count; i++)
            wbs[i].Close(null, null, null);
            System.Runtime.InteropServices.Marshal.ReleaseComObject(wbs[i]); // release it
            wbs[i] = null; // null it
        exc.Workbooks.Close(); // so you can close this
        exc.Quit(); // so you can quit this
        System.Runtime.InteropServices.Marshal.ReleaseComObject(exc); // release it
        exc = null;
        GC.Collect(); // this sets up the finalizers
        GC.Collect(); //apparently this kills it
    catch (Exception ex)
        // deal with it fool!

Yes this is overkill, but I think I covered all possible ways to kill you processes, so they should be more dead than Elvis; no more orphans - yay for iteration!


Some useful links: 

Converting an Excel Spreadsheet to a DataSet, DataTable and Multi-Dimensional Array

A way to easily manipulate data from an excel spreadsheet programmatically

I work in an office environment which is dominated by Microsoft Excel spreadsheets, and so often, people want to use them in programs.  I am a SQL junky myself, but Excel is appropriate in a lot of cases, but integrating them into programs can be a pain.  More specifically, getting the data from the Excel worksheet to a form where it is workable can be a pain. 


With this example, you can see how to take in an Excel Spreadsheet to get the data into commonly manipulatable data types in c#; then you can use/change it however you want to.  This demo shows first how to put the data into a dataset, then datatable (almost the same thing), then takes the same data in puts it into a multi-dimensional array (I prefer to work it arrays).  Since this is a linear progression, the demo only outputs the information from the array into an html table to show that it worked. 


The demo uses the very first row as the column names (as it is used in datatable) and assumes that the Spreadsheet is in default format with Sheet1 as it's first sheet.  The demo only processes Sheet1.  This can be easily customized if you want to process more. 


With this, you can take/change/display the excel data however you want to using controls like ListView or GridView or just simple c#.  The code is pretty well commented, so you should be able to pull the parts that you may need.  *NOTE: you need full trust enabled for this to work properly.