Eureka!

The installation procedure of SBS2003 has not been going as smooth as I had planned. Every time I attempt to install it (must be about 5 times now) there are some issues with the Server Tools or the Server Monitoring Tools not installing correctly. No matter what I seem to do, these always fail. I’m about to give up on it, thinking that it must be my hardware.

Oh, on another note, I ordered a copy of the French localization of SBS2003. Unfortunately, I can’t use it, and if anyone want to purchase it from me, or trade it for an english version, please contact me.

I finally completed the downlaod for the long-awaited Windows Longhorn Beta. My first impressions as I am going through the installation process are (to say the least) are that of surprise, and relief at the same time: Microsoft is finally putting total emphasis on usability and have totally rethought the user interface. The setup process is now totally graphical, and it only requires two steps: a) what partition to install it on, and b) what name you will give this computer. It then proceeds to do the complete installation on its own. Right now I’m waiting for that to finish up, so more on this as I go along.

[Edit 7/31/2005 00:56]
Well, it finally finished it’s install. And the user interface is georgous. Now downloading the 64-bit version to install on my AMD Athlon64 machine. Being that VISTA is backwards compatible, I will try to use it for everyday use and see what the benefits really are. This link has some really great info: http://www.winsupersite.com

As a complete small business package, Windows Small Business Server 2003 has the following benefits to offer:

• Centralized Storage
• Simple Backup and Recovery
• Simple and Effective Security
• Reliability
• Remote Connectivity
• Colaborative Environment
• Support for Line-of-Business Applications
• Streamlined Configuration Process
• Streamlined Upgrade Process

As our business has employees across the united states, we are a very decentralized environment. This posed very specific problems for communication, delegation, and team management. Centralized storage is an absolute must in our environment. We must have all documents, resources, and information available on demand to any of our team members, so that we can do our job effectively. in our current Linux system that is not the case. We have planned to develop and impliment an online web-based file sharing system where we can upload and store our documents and other resources. Immediate drawbacks are appearent: the system isn’t developed yet, will take time and resources to create, and it isn’t easily integratable into other software and has very limited and specific functionality. Over the next week or two I will evaluate how this feature of SBS2003 works. On paper it sounds like a great solution to our dilema.

More to come …

Well, our company is and a turning point. We are currently faced with the decision to either move to a non-Microsoft environment where we would set up our desktops, servers, and what-not on Linux, or, move to a complete Microsoft environment, where our desktops run on Windows XP, our servers on Windows Server 2003, and our websites are in ASP.NET, etc.

Until now we were trudging along with the goal of running our business in a non-Mocrosoft, say, Linux, environment for the following reasons:

• Cost savings - Linux software is for the most part free and OpenSource.
• Secure server and network environments (less virus’, spyware, etc.).
• Product flexibility.

However, we are comming to realize, much to our dismay, that as much as we dispise what Microsoft stands for (Monopoly, exclusion of competition, market control, etc.), they do make things very easy for businesses. Only as long as you use Microsoft software across the board of course. Here are the drawbacks we are currently facing in our non-Microsoft environment, which let us to our current fork-in-the-road situation:

• Maintenance, development, custom content creation, etc. is all very time-consuming and tedious.
• We would have to create our own team-system for collaboration, file-sharing, etc. that fits our specific needs.
• All our focus and effort spent on creating our internal business infrastructure would dramatically decrease our productivity and not let us accomplish what we started the business for in the first place.

There we now have the pros and cons of the non-Microsoft environment. I am currently evaluating a total Microsoft-oriented environment to see how well it stacks up against the other scenario (Linux), as well as to see if it can provide a all-encompasing package, so that we don’t have to go out and purchase 3rd-party software. This includes the following:

• Windows Small Business Server 2003
• Live Communications Server 2005
• * Windows XP
• * Office Profesional Enterprise 2003
• * Office OneNote 2003
• * Visual Studio 2005

* denotes items installed on users’ desktops, unmarked items are installed on the server.

Over the next couple of posts I will evaluate each of these in comparison to a Linux equivalent that we are currently using. I would also be eager to hear your thoughts and experiences on this subject: please do comment!

Say you are changing information in you app against a dataset, then you can view the changes you have made at any time by utilitising various tracking methods of the dataset. These include .HasChanges(), .GetChanges(), etc.

Transaction processing is an absolutely vital part of developing database applications. It allows for commits and rollbacks. So, in the event that something unforseen should occur, you can roll back all your SQL statements and handle the exception, then make the necessary adjustments, and run the scripts again. Here is a short example:

Dim objConn As New SqlConnectionDim objComm As New SqlCommandDim objTran As SqlTransaction

Try   objConn.ConnectionString = "server=(local);database=northwind;integrated security=SSPI"   objConn.Open()   objTran = objConn.BeginTransaction(IsolationLevel.ReadCommitted)   objComm.Connection = objConn   objComm.CommandType = CommandType.Text   objComm.CommandText = "INSERT INTO blog (entry) VALUES ('" + txtEntry.Text + "')"   objComm.Transaction = objTran   objComm.ExecuteNonQuery()   objTran.Commit()   objConn.Close()   LoadBlog()Catch objError As Exception   objTran.Rollback()   MessageBox.Show(objError.Message)End Try

You will immediately notice that I roll back any SQL queries that happened after the transaction object was set if any error should occur. This means that if anything goes wrong, the database does not get updated. You can see where this is going: for maintenance, batch processes, etc., you should always be using transaction processes, so that if one statement should fail, it wont corrupt other dependant data.

1. When working with datareaders and stored procedures, and your stored procedure returns a paramter value, you must close the datareader before you can access the parameter value. Microsoft says its not a bug, but missing functionality is just as bad as erroneous funcitonality. So: BUG!
2. You can call .ExecuteScalar on queries that return multiple rows (for some reason, eventhough it makes no sense), however, it will only return the first field of the first row.
3. You can bind datareaders to web objects when in ASP.NET, however, you can only bind datareaders to datasets, data tables, and data views when working in VB.NET.
4. You must ‘prime’ a datareader before accessing its content, like so:

   While reader.Read()[...]End While

5. When retrieving data from datareaders using the various get methods, only the SQL data type get methods allow for NULL values. Using the get methods uses less overhead, since the data is returned as that explicit type and not as an object.
6. Multiple selects can be executed at the same time using a single data reader. This can be usefull for minimizing resource usage when initializing data when opening an application or loading a web app. Consider the following (note reader.NextResult(), which moves to the next SQL statement in the datareader results):

   comm.CommandText = "SELECT * FROM customers;SELECT * FROM products"reader = comm.ExecuteReaderWhile reader.Read()   [...]End WhileIf (reader.NextResult()) Then   While reader.Read()       [...]   End WhileEnd If

When connection to a database, or even when executing queries, inserts, updates, and so forth, one should ALWAYS attempt to catch the SQL exceptions apart from the regular catching. This provides more detailed feedback than the regular exception handling:

        Try           'SQL processing here       Catch objError As SqlException           'this will catch all errors on the SQL side (SELECT, INSERT, UPDATE, etc.)           'note that this does not handle errors opening and closing the database           MessageBox.Show(objError.Number + ": " + objerror.Message)       Catch objError As Exception           'errors when opening and closing the database are handled here           MessageBox.Show(objError.ToString + ":" + objError.Message)       End Try

Weirdly enough, in the new .Net it’s OK to close a closed connection (can’t close anything you haven’t opened?!), but it raises an error if you try to open an open connection! In my opinion you shouldn’t rely on being able to close a closed connection in your programming,

    Private Sub btnOpen_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnOpen.Click        Try            If (objConn.State <> ConnectionState.Open) Then                objConn.Open()            End If        Catch objError As Exception            MessageBox.Show(objError.Message)        End Try    End Sub

    Private Sub btnClose_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnClose.Click        Try            If (objConn.State <> ConnectionState.Closed) Then                objConn.Close()            End If        Catch objError As Exception            MessageBox.Show(objError.Message)        End Try    End Sub

Here objConn is a SQLConnection object from the toolbar dragged onto a webform. The two functions are fired by two buttons on the windows from denoting an open event and a close event.

In order to correctly connect to your database, you’ll need a connectionstring. There are so many different types of connections you can create, that you might be stumped for a bit if you’re required to create a strange connection. Well, here’s the solution to all that: this website lists all (or very nearly) of the possible connection strings you could ever want: http://www.carlprothman.net/Default.aspx?tabid=81 or http://www.connectionstrings.com. All you need to do now is look up what you need to connect to, and this site provides how you need to create your connection string! Nifty!