Peter Bromberg's UnBlog

NOTE: There is a more complete article on eggheadcafe.com here .

I’ve got an x64 machine I do most of my “hard core” development work on, that I’m very happy with. I’m running Windows 7 Ultimate x64 and have had few problems. The box only has 4GB RAM, but I almost never hit the ceiling with that, no matter what the heck I do. But recently, we needed to do some work on a database that has some tables with close to 6 million rows, and I needed to build FullText catalogs for some of them. That’s where SQL Server 2008 x64 crapped out . I had memory consumption issues that caused me to have to hold the power button down for 4 seconds just to be able to “get out of Dodge” if you will -- several times too. Mouse didn’t work, machine was unresponsive, etc. – just building a FullText catalog on this big table. Now I don’t care about all the KB’s and suggested “Fixes” and all that. I haven’t got the time to futz with this crap. So I said, OK, let’s get rid of this sucker and see if the x86 version of SQL Server 2008 does better. So I did, and guess what...

  For quite a while I could not install SQL Server 2008 SP1, as it reported a failed shared component installation – in this case, Books Online. Problem is I could not find the source MSI to fix it. So here is how I solved the problem:  If any shared components installations result in a failed state, a Registry key is updated. SP1 reads these keys when it starts, and if the value is not “1” (in my case it was “3”) – it will stop. Seems ridiculous to me, but that’s how they do it. And doing a repair may not fix it either – because you may have installed Books Online from an interim standalone MSI installer. if you try to find the original MSI to handle the repair, it might not be the correct one. Edit this key (or the respective key for whatever your fail message says) and ensure that the value is 1: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\ConfigurationState\Sql_BooksOnline_Redist That took care of that problem! Now I have a different issue, b...

This is pretty slick. The Database file sizes are small (Northwind = about 2MB), the assemblies to add to an application are small. It supports replication and a lot of other features. No stored procs, but it supports Views and full relational integrity. You can deploy it in a regular MSI project by simply adding the seven dll's and your database file.   Best of all, your System.Data.SqlCe namespace works exactly like the System.Data.SqlClient one. For example in a small Windows Forms test app:   private void Form1_Load(object sender, EventArgs e)         {             string cnstr=@"Data Source=C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\Samples\Northwind.sdf";            System.Data.SqlServerCe.SqlCeConnection  cn = new SqlCeConnection(cnstr);             SqlC...

The best minds are not in government. If any were, business would hire them away. - Ronald Reagan I was working with a partner on testing his MSI Installer for various operating systems, and on Windows Server 2008 x64 it was continuing to come up with this error: Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified. (Microsoft.SqlServer.ConnectionInfo) I checked the signature of the local assembly in the installation folder against the one in the GAC, and they were identical. So, go figure, right? It turns out that the solution is very simple: Unless you've installed the 64-bit verion of SQL Server 2005, you need to install the 64-bit version of SMO. It's not there by default. If it is not installed ,you can download the 64 bit version from http://download.microsoft.com/download/4/4/D/44DBDE61-B385-4FC2-A67D-48053B8F9F...

Some time ago I presented an article about why XOR encryption can be a useful "just enough" technique to easily handle encryption and decryption of strings such as connection strings in configuration files. By carefully choosing the value to use as the operand in the XOR function, we can create an encrypted string that is "XML Safe". One such ASCII value I found was the integer 129. The advantage of XOR is that it is bidirectional - when you XOR the result of a previous XOR operation, you get back the original value. This means you only need one method to both encrypt and decrypt a string. I should hasten to note that XOR encryption is NOT a strong encryption algorithm - it's probably one of the first things a determined hacker would try. However, for simply keeping your stuff "away from prying eyes" -- it can often be "just enough". The following example illustrates how one can create a UDF in SQL Server to perform the same operation. CREATE...

I've been going through the learning curve with CodeSmith and the initial results are pretty interesting, especially with the free NetTiers template set. Man, does that generate a bunch of stored procs, entity and domain objects and controls! If you get used to the model, you are virtually going to get yourself an entire application in one 5-second CodeSmith "Swoop"! One of the things I came up with while monkeying around with the Database schema was the need to delete all the generated stored procs so CodeSmith can be pointed back at a "procedure-less" database for another take. The problem is you don't want to just select everything with type 'p' from SysObjects - because there are system procedures there such as for diagrams. Also, you cannot just do an ad-hoc delete, because you'll get an error message; Sql Server is trying to prevent you from shooting yourself in the foot. Here is an easy way to do it: First, right - click on the query pane...

In your travels as a professional software developer, especially when you come into a new position and need to get used to a new enterprise and its programming - related environment - the tools, the programming style, the existing codebase, etc. you get to observe some of the repetitive coding patterns that people resort to in order to solve their problems. One of the most common ones I've observed is where developers do not have a full understanding of how ADO.NET and connection pooling work. It seems almost like instead of seeking out and using best-practices code and techniques, that some people, either through lack of knowledge or just plain being stubborn, feel compelled to "roll their own" DAL and Database layers. Mistakes and poor design often result. Back around 2001, I found the Microsoft Data Access Application Block ("SqlHelper") class, which quickly solved a whole bunch of data access problems for me, and in fact I still use it today - 5 years later ...