Tag Archives: C#

You asked: Sharp+Develop+ODBC+example

I had that question appear in my logs a couple of times, and I assume, these are (beginning) .Net developers who want to have examples of accessing database servers via ODBC in C#. If you thought this was going to be ‘plain and simple, drag and drop in Visual Studio’ (or SharpDevelop), you are partly wrong. As in everything in programming, you end up doing a lot of coding yourself because of certain limitations.

First of all, Visual Studio 2005 (SharpDevelop might) by default does not have the (visual) ODBC controls installed in the ‘Toolbox’. You need to add them yourself (there should be 4 of them). After doing that, you’ll find out that using these ‘visual’ controls is not as ‘visual as that fancy commercial promised’. Worse, you read in the Framework documentation that:

While the OdbcDataReader is being used, the associated OdbcConnection is busy serving the OdbcDataReader, and no other operations can be performed on the OdbcConnection other than closing it


Due to the limitations of native ODBC drivers, only one DataTable is ever returned when you call FillSchema. This is true even when executing SQL batch statements from which multiple DataTable objects would be expected.

There’s generally two ways to get and retrieve data using the .Net 2.0 Framework: the first one is to use the earlier mentioned DataReader, the second one is the ‘in-memory cache’ DataSet/DataTable. Most of time, you’ll end up using a combination of both: when there’s lots of data involved you may want to skip the DataSet and go for the DataReader (wrap it in an object for example). If you want to keep data in memory and want to keep connections open (persistent), you may want to keep close attention to the first quote I mentioned above.

But the good stuff is right here (warning: untested code ahead! All disclaimers apply). If you’re not into programming, you may want to skip this:

Continue reading

I can do this too…

Yes, so I needed to get into an older site and I forgot the password, because, well, back in 2000, I used an FTP program (FTP Explorer) that (at that time) was pretty popular. So, late last year, I was transferring data from the oldest laptop (Proteus) which had a copy of that FTP program. Before wiping the drive (refurbish, refurbish!), I was smart enough to preserve the FTP program’s registry entries and save them for future reference, hoping I might be able to break the algorithm one day.

Not shortly after, I ran into some code that purportedly showed the algorithm to decrypt the FTP program’s entries and passwords, however, completely written in Perl (link to Google cache). Luckily, I have no problems understanding Perl and it only took a couple of minutes to rewrite it in C#.

So, there you have it: the C# sources you can find right here. Coding was done in SharpDevelop. Note that you need to compile and build the executable yourself and if you want, you can probably rewrite it in your other favourite programming language. Whatever.

That said, it was fun while it lasted. Ta-daa old website.