GotSharp.Extensions is a .NET Class Library containing extension methods and utility classes. Right now, it contains only some extension methods for the System.String and System.IO.Stream classes, and the utility class Range (with implementations Int32Range and DateTimeRange). We will keep updating it however with new functionality. Feel free to give comment or feature requests, but please do so on the project page, hosted at CodePlex.

• Parameter name is different in the query and when declaring the parameter (wrong columnName, or wrong parameter assigned – the copy/paste error)

• The parameters are not in the right order (especially true when querying Microsoft Access databases)

 
Because you’re reading this, you can assume by now that I hadn’t found a solution for my problem.  Well, that’s not entirely true, but I still needed another solution to completely solve my problem.

First issue: the order of parameters was incorrect. But when you google around for query expression in Access, you’ll see two ways for defining parameters: using question marks, or a parameter name.  I was using parameter names, and expected that the DbCommand object (actually a OleDbCommand object) would map the parameters correctly.

It appears that I was wrong.

Whether you use names or question marks doesn’t matter when the command object is mapping the values, it just fills up the parameters in the query one by one.

Second issue: I’m using Nullable’s in my model class.  For those who don’t know what Nullable is: ever had a DateTime in a model class and a “datetime” field in a database table with NULL as its value?  What value did you give your DateTime field? DateTime.MinValue? Or did you keep track whether the value was set or not with a boolean?
Nullable was added to the .NET Framework 2.0 for this problem.  You can use it to wrap basic data types and structures, like int (Integer), decimal (Decimal), DateTime, …

In C#:

Nullable<int> nValueOrNull;
OR
int? nValueOrNull;

In VB.Net:

Dim nValueOrNothing As Nullable(Of Integer)
OR
Dim nValueOrNothing? As Integer
OR
Dim nValueOrNothing As Integer?

Note that the last two ways of defining a Nullable in VB.Net are only available from .NET Framework 3.5 and higher. More information: http://msdn.microsoft.com/en-us/library/ms235245.aspx

Now, when I assign a field (which is a Nullable<int>) to a parameter object, and that field contains no value (I deliberately didn’t say: that field is null), I expected that the command or even the parameter itself would translate that to NULL in the database, especially because the IsNullable property of the parameter was set to True.  Of course, I was wrong about my assumptions.  After trying some things, eventually I tried passing DBNull.Value when my field contained no value: that did the trick.

So, in short: null (or Nothing) is NOT the same as DBNull.Value when assigning values to query parameters.  Nullable can help you matching a model class to a database table, but doesn’t help when translating DBNull from a query result or to a query parameter.

Apparently, there is a bug in the kernel when looking up the LMHOSTS table, causing the CPU to enter a semi-infinite loop. Semi-infinite, because the thread times out after a few seconds.

For more information, look here (original forum post) and the KB article at Microsoft (more specifically, workaround #2).  Although the KB article is originally for Windows Server 2003 platforms, it also applies to Windows 7, just don’t try to install the hotfix on you Windows 7 machine!

The FoxPro ODBC driver seems to have problems setting the pointer when you set the memo of a row using a RecordSet.  If there are other rows after the current one with empty memo fields, the driver sets the pointer in those rows as well. Examine the following code:

rs.Open ...
While Len(sMemoData) > 254
    rs.Fields("Memo").AppendChunk Left(sMemoData, 254)
    sMemoData = Right(sMemoData, Len(sMemoData) - 254)
Wend

If Len(sMemoData) > 0 Then rs.Fields("Memo").AppendChunk sMemoData
rs.Update 

To avoid this from happening, you can use a ADO Command object and use parameters instead.  Make sure you set the correct size in the parameter!

cmdAdo.CommandText = "UPDATE table SET Memo = ? WHERE Field = 'a value'"
Set pMemo = cmdAdo.CreateParameter("Memo", ...)
pMemo.Size = Len(sMemoData)
pMemo.Value = ""

While Len(sMemoData) > 254
    pMemo.AppendChunk Left(sMemoData, 254)
    sMemoData = Right(sMemoData, Len(sMemoData) - 254)
Wend

cmdAdo.Execute 

public class CustomPatternLayout : PatternLayout {
        protected override PatternParser CreatePatternParser(string pattern) {
            PatternParser parser = base.CreatePatternParser(pattern);

            //usage: %CustomField or %cf (case-sensitive)
            parser.PatternConverters["CustomField"] =  typeof(CustomPatternConverter);
            parser.PatternConverters["cf"] =  typeof(CustomPatternConverter);

            return parser;
        }
    }

Fortunately, we have Google! After a quick search I found someone with the same problem and a solution.  By simply invoking (and postponing) the SelectAll call, it will work.  The MaskedTextBox has its own selection thing going on in it’s Focus event handler, that’s why just doing SelectAll doesn’t work.

Here’s what you must do: (C#)

private void txtMaskedTextBox_Enter(object sender, EventArgs e) {
    this.BeginInvoke( (MethodInvoker) delegate() {
        txtMaskedTextBox.SelectAll();
    } );
} 

You can’t use anonymous delegates in VB.Net 2005 (don’t know if you can in VS 2008), so you must create a new delegate and method.  But you can make it more generic at the same time, because I’ve also seen normal TextBoxes behaving like this from time to time.

Private Delegate Sub SelectAllInvoker(txtBox As TextBoxBase)

Private Sub SelectAll(ByVal txtBox As TextBoxBase)
    txtBox.SelectAll()
End Sub

Private Sub txtMaskedTextBox_Enter(ByVal sender As Object, ByVal e As EventArgs)
    Me.BeginInvoke(New SelectAllInvoker(AddressOf SelectAll), _
                   DirectCast(sender, TextBoxBase))
End Sub 

Visit this page for more information, the download link and future updates.

Just register yourself on this website, and send an e-mail to contribute [at] gotsharp [dot] be containing the username you used to register yourself, and some details about yourself (especially about your .NET abilities).  We will get back to you as soon as possible to inform whether you are accepted as a contributor or not.

The answer to solve this is multithreading. But writing a multithreaded application can be quite difficult. If you rush into coding, you quickly forget about locking shared data, resulting in possible deadlock situations. And even when you have a relatively simple algorithm that you want to run in a second thread, like copying lots of files or preparing a Crystal Report document to print, it can be quite troublesome to reach that goal. Especially if you want to give feedback while executing the thread (like a ProgressBar that gradually fills up), or support cancellation.

In .Net 2.0, it doesn’t need to be so difficult. You can easily make most simple tasks (and perhaps even some of the more complex ones) multithreaded by using the BackgroundWorker control.

The BackgroundWorker control, when you add it to a Form, sits in the Component Tray (the gray area that holds all controls that are never visible on a Form). At Design Time, you only need to worry about the WorkerReportsProgress and WorkerSupportsCancellation properties. If your BackgroundWorker instance is going to report progress in the task(s) it will perform, you should set WorkerReportsProgress to true. If you want to enable the user to cancel the task(s), you should set WorkerSupportsCancellation to true.

To implement the BackgroundWorker, you need to use the DoWork event. When the application requests that the BackgroundWorker starts its thread, the BackgroundWorker fires the DoWork event.
Two other events to look at are ProgressChanged and RunWorkerCompleted. If you report a progress update, the ProgressChanged event is fired so you can update a ProgressBar, or maybe a Label that holds information about what the application is doing. The RunWorkerCompleted is fired when the BackgroundWorker ends its thread (usually after exiting the DoWork event handler). You can use that event to restore your UI to a specific state, like re-enabling buttons that were disabled while running the task(s).
Before we begin with our example, some important notes: in the DoWork event, you can not access the UI of the Form. This is typically the case when you’re in another thread (the UI runs in its own thread): the Framework disallows you to “jump” to the UI thread when your not currently there.
That’s the reason why there is a separate ProgressChanged event. When you report progress updates, the BackgroundWorker invokes the ProgressChanged event on the UI’s thread (or in other words, the BackgroundWorker makes sure that the Form controls are accessable inside the ProgressChanged event handler).

Example

Let’s say that you want to copy a folder that contains approximately 1 GiB of data. This might take a while, and you want to inform the user of the progress and enable him to cancel the process.
Typically, you would show a modal status Form, to keep the user from pressing buttons in another Form (think of the copy file dialog that appears when copying files in Explorer).

Download example solution (VB.NET project): BackgroundWorker Sample
This zip file contains the solution and VB.NET project.  Created in Visual Studio 2005, but you should be able to open it with Visual Studio 2008 as well, either bought or Express editions.

I am Wesley Cabus, a software architect at Quality Software bvba in Belgium. Currently, I’m mostly active in JavaScript inside CaseWare Working Papers.  I’m also experimenting with the .Net platform in my time off, trying out some challenging stuff (i.e. threading, reflection) and the latest new technologies (WPF, LINQ, …).