Using Sql Profiler 2014 to debug SqlCommand in C#

I found the SqlCommand C# class is tricky to debug in Visual Studio if you are using SqlParameter and you want to see the exact statement being executed on the server.

First of all, run a test query on a table in the database, you will need to run your C# application to generate the query. This will create an entry in the process list for that database, which you can filter in Sql Profiler 2014.

select * from master..sysdatabases
select * from master.sysprocesses where dbid = 11

Look for the database id (dbid) of the database you ran the query on, and then find all processes running for that database. In my case, the dbid was 11 and I ran the query to get all processes for that database.

Scroll to the program_name and copy the value.
Note: Remove any extra spaces, as the Sql field in the result will be padded with spaces.





Open up the Profiler, create a new trace. In my case, I only want to see the final command being executed, so I ticked SQL:BatchCompleted only, and unticked all the other events.

Click 'Column Filters...', under 'ApplicationName' paste in the value you got from the process list (program_name).

Remember to remove any extra spaces, otherwise the Profiler will not be able to match it correctly, this is a common mistake!


 


Run your trace and execute your Sql commands either from a test query or your C# application.




You should notice that the commands are easily checked in Sql Profile 2014 now and you can test your C# application by matching its program_name from master..sysprocesses.

You can filter the events neatly to only show the application you are debugging by ticking SQL:BatchCompleted event and filtering by Column item ApplicationName.

The "Bus Factor"

I had not heard this before but a bus factor is the risk that if one of the developers in the team were to be hypothetically hit by a bus, then this reflects on how it would affect a project.

One of the obvious factors would be an immediate deficit in knowledge and experience. But it also highlights the problem of a single point of failure, where only one person is responsible for particular areas of the project.

I thought about this and it seems to me that there should be more paired programming, so that junior members are exposed to the processes of the more experienced developers. Over time and with experienced supervision, in a kind of mentor relationship, both parties will exchange important practical knowledge and experience until juniors could perform similar work as more experienced developers.

The idea is to have as many people as possible with practical knowledge about the project, so that anyone can jump in and take up the slack when the 'person hit by the bus' is not available.

Disappearing TabPage Title Text when adding to a SplitContainer Panel

On a project we had a problem where TabPage title text would disappear when a TabPage was added to a SplitContainer Panel. For a while I did not know how to solve this issue because it was not obvious what was causing it.



After some research, it appeared to be a known Microsoft issue as described in this post: https://bytes.com/topic/c-sharp/answers/457492-tabpage-text-disapearing

However, I was not convinced this would be an ideal solution. I wanted something quick and simple. I ran a test and noticed when adding TabPages to the test SplitContainer, that the TabPage title did not disappear. Also the test did not contain a MenuStrip control, which the client app did.

Then I suspected the menu was causing the problem, because it was overlapping the TabPage title, and the title text was not disappearing at all.

To solve it, I simply added some padding to the SplitContainer panel, to push it below the MenuStrip in the client application. Here is some code.

SplitContainer1.Panel1.Padding = new Padding(0, 27, 0, 0); 

27 represents the default height in pixels of a MenuStrip, the top padding on the SplitContainer panel should then clear the menu and the title text will show.

Accessing Microsoft Excel without using Interop

In a recent project, the server we deployed to did not have Microsoft Office installed, it only had Microsoft Excel loaded for some reason.

We could not use the C# Microsoft Interop Services to access Excel, and it came up with the error "Could not load file or assembly 'Microsoft.Office.Interop.Excel', or one of its dependencies. The system cannot find the file specified."

After searching and not finding much about accessing Excel without using Interop, I stumbled upon an old post from decades ago about using Visual Basic and its CreateObject, GetType, InvokeMember and CallByName functions in the Interaction interface.

Such a godsend, after a few tests I was then able to access Excel through its COM component.


You can check Workbook member properties here: https://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel._workbook_members.aspx


Here is some code to show the process to access the Excel COM Component, it may need adjusting for your own project.

using System.Windows.Forms;
using Microsoft.VisualBasic;
using System.Reflection;
using Microsoft.Office.Interop;

PrintDialog PrinterForm = new PrintDialog( );
string FileNamePath = "C:\\ExcelFile.xlsx";

// Create COM object to Excel Application.
Object XLApp = Interaction.CreateObject("Excel.Application");

// Get COM object Excel Workbooks interface.
XLApp.GetType().InvokeMember(
"Workbooks", BindingFlags.GetProperty | BindingFlags.Public, 
null, XLApp, null);

// Test getting Workbooks interface from XLApp COM Object.
Object XLWorkbooks = Interaction.CallByName(
XLApp, "Workbooks", Microsoft.VisualBasic.CallType.Get, null);

// Call Open method on Workbooks interface.
// Pass it the filename parameter.
// Excel COM object should then issue command to Excel.
// Excel to open the filename (xlsx).
Interaction.CallByName(XLWorkbooks, "Open", 
Microsoft.VisualBasic.CallType.Method, FileNamePath);

// Debug (Workbooks object).
// string WorkbooksString = XLWorkbooks.ToString();
// MessageBox.Show("WorkbooksString = [" + WorkbooksString + "]", "Debug");
// Show print form to user.
if (PrinterForm.ShowDialog() == DialogResult.OK)
{
// Cast XLWorkbooks to Workbooks collection.
Microsoft.Office.Interop.Excel.Workbooks XLWorkbooks2 = (Microsoft.Office.Interop.Excel.Workbooks)XLWorkbooks;

// Iterate Workbooks collection.
foreach (Microsoft.Office.Interop.Excel.Workbook XLWorkbook in XLWorkbooks2)
{
// Debug (XLWorkbook).
// MessageBox.Show("XLWorkbook String = [" + XLWorkbook.ToString() + "]", "Debug");
// Print workbook to user specified printer.
XLWorkbook.PrintOutEx(
Type.Missing, Type.Missing, Type.Missing, 
Type.Missing, printDialog.PrinterSettings.PrinterName);

// Close workbook.
XLWorkbook.Close(false);
}
}

// Close COM Excel.
Interaction.CallByName(
XLApp, "Quit", 
Microsoft.VisualBasic.CallType.Method, null);