Quite often when working with ASP.NET projects in Visual Studio 2005 it is very tempting just to add the database to the project as a new item. But how on earth do you add the useful ASP.NET database design to a database that cannot be found on your server instance? After a very short Google search I found the answer here Using ASPNET_RegSQL.exe with SQL Express databases in APP_DATA, thank you Lance!
Read more!
Sunday, September 30, 2007
App_Data databases and aspnet_regsql
Posted by
Robin Theilade
at
16:41
0
comments
Links to this post
Labels: asp.net, aspnet_regsql, database, express, sql, visual studio 2005
Saturday, September 29, 2007
Descriptions on MS SQL 2000 computed columns
At work I was given the task to write descriptions on all the tables and their columns on the project I'm working on. I spoke with my boss about writing the descriptions on the SQL server instead of using Visio due to prior "challenges" with Visio. The advantage of writing the descriptions on the SQL server is that if the database was reverse engineered in Visio, Visio would include the descriptions when reverse engineering and the same should be possible with other database design systems. Luckily my boss could see the advantage and gave me green light.
Anyway, it all went very well and a lot quicker than I first imagined until I got to the point where I needed to describe two computed columns. Enterprise Manager had disabled the description column for those two columns so it wasn't possible to change their description. At first I just added the missing descriptions as a text object in a SQL server diagram object which contained the owning table. But then I changed my mind and started investigating where the descriptions were stored on the server.
I found out that a table named "sysproperties" was storing the descriptions. "Easy as pie" I thought to my self, "I'll just insert a new row for each of the two columns". But it didn't take long to find out that I wasn't allowed to insert new rows into the table. But since when have that stopped anyone?
After a quick Google search I found the solution:
RECONFIGURE WITH OVERRIDE
INSERT INT [sysproperties] VALUES ( @tableId, @columnId, 4, 'MS_Description', @description )
SP_CONFIGURE 'ALLOW UPDATES', 0
RECONFIGURE WITH OVERRIDE
@tableId
This variable represents the ID of the table who owns the columns in question. You can find the ID of the table by selecting it from "sysobjects" using the statement:
FROM [sysobjects]
WHERE [name] = '<your table name>' AND [xtype] = 'U'
@columnId
This variable represents the ID of the column in question. You can find the ID of the column by selecting it from "syscolumns" using the statement:
FROM [syscolumns]
WHERE [id] = @tableId
@description
This variable contains the description that you would like to store.
OK, so now the descriptions were in place, and although Enterprise Manager didn't show the descriptions they were still included when reverse engineering in Visio.
NOTE #1: In Microsoft SQL server 2005 you are able to change the description of a computed column.
NOTE #2: Although you might get the idea that I approve the existence of Visio, I can assure you it is not true! I only use Visio at work to see if the department would gain anything by switching to Visio in the future.
Read more!
Posted by
Robin Theilade
at
15:55
0
comments
Links to this post
Labels: columns, descriptions, microsoft, server, sql, sysproperties
Thursday, September 27, 2007
Form event that is only raised the first time the form is shown
Early this week a couple of my colleagues and I had a little discussion about events on the System.Windows.Forms.Form class. We were discussing if the Form had an event that would only be raised the first time the form was shown and never again. Personally I believed that the Form.Load event was doing just that, but after that discussion I was in great doubt so I decided to investigate it a little further.
I started by defining a list of the events that I thought could be interesting in the test:
Now for the test. My first test was simply to call the Show and Hide methods on the form. Given the results I thought that both my initial assumption and the assumption of one of my colleagues were correct: The Load and the Shown event was only raised once.
20070927 21:20 - Deactivate
----------------------------------------
20070927 21:20 - Activated
20070927 21:20 - GotFocus
----------------------------------------
20070927 21:19 - LostFocus
20070927 21:19 - Deactivate
----------------------------------------
20070927 21:19 - Shown
20070927 21:19 - Activated
20070927 21:19 - GotFocus
20070927 21:19 - Load
20070927 21:19 - HandleCreated
However after the next test I realized that I was wrong. This test was about calling the ShowDialog method and then use the forms "X" button to close it again.
20070927 21:28 - LostFocus
20070927 21:28 - Deactivate
20070927 21:28 - FormClosed
20070927 21:28 - Closed
20070927 21:28 - FormClosing
20070927 21:28 - Closing
20070927 21:28 - Shown
20070927 21:28 - Activated
20070927 21:28 - GotFocus
20070927 21:28 - Load
20070927 21:28 - HandleCreated
----------------------------------------
20070927 21:28 - HandleDestroyed
20070927 21:28 - LostFocus
20070927 21:28 - Deactivate
20070927 21:28 - FormClosed
20070927 21:28 - Closed
20070927 21:28 - FormClosing
20070927 21:28 - Closing
20070927 21:28 - Shown
20070927 21:28 - Activated
20070927 21:28 - GotFocus
20070927 21:28 - Load
20070927 21:28 - HandleCreated
What surprises me here is that the HandleCreated and HandleDestroyed is called every time you call the ShowDialog method and when the form closes again, but the Handle stayed the same while I ran the test.
The solution must be to create your own event that uses a boolean to indicate whether or not the form has been shown.
Read more!
Posted by
Robin Theilade
at
21:07
1 comments
Links to this post
Labels: .net, events, programming, shown, system.windows.forms.form
Tuesday, September 25, 2007
Hello Eartlings!
For my first post I would like to clear the air about System.String objects. Since the dawn of time humans have all been trying to figure out if two identical strings actually points to the same space in memory. And I might just have the answer!
Last week a colleague of mine rejected the possibility of two identical string objects would share the same space in memory. So I thought about it and wrote a little test.using System;
namespace StringReferenceTest{ public class Program
{ static void Main(string[] args)
{ String string1 = "Hello World";
String string2 = "Hello World";
Console.WriteLine(String.ReferenceEquals(string1, string2));
Console.ReadLine(); }
}
}
and the result
As you can see this little quick test told me that the two string objects had the same reference. But this didn't really satisfy me, why not go a little further and get the two objects memory address?using System;
namespace StringReferenceTest{ public class Program
{ static unsafe void Main(string[] args)
{ String string1 = "Hello World";
String string2 = "Hello World";
Console.WriteLine(String.ReferenceEquals(string1, string2));
fixed (char* p = string1)
Console.WriteLine((IntPtr)p);
fixed (char* p = string2)
Console.WriteLine((IntPtr)p);
Console.ReadLine(); }
}
}
and the result
Again the test told me that the two string objects were referencing the same address. Notice for this last test to work you need to specify the "unsafe" statement in the method signature and set the project's build settings to allow unsafe code.
So now you know :)
Read more!
Posted by
Robin Theilade
at
22:37
0
comments
Links to this post
Labels: .net, c#, programming, system.string

