Showing posts with label Access. Show all posts
Showing posts with label Access. Show all posts

Tuesday, 14 May 2013

Connection Strings


Referring back to my initial attempt to port the existing VB6 application from MS Access to SQL Server by changing the connection string, one of the aims of Project Sputnik is to try to make it DB independent. Before my recent trip abroad my techie nerd/guru friend and former colleague put me on to a method which I believe will help me achieve this. The application will have a separate configuration file for the connection string (than App.Config) and the DAL will have a class that reads the connection string from this file. By writing ANSI compliant SQL in the DAL concrete classes I hope to achieve the goal to be DB impartial.

The App.Config file in the recent DAL Test Harness looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
       <connectionStrings configSource="connectionstrings.config" />
</configuration>

I added a configuration file called ConnectionStrings.Config and set the file property ‘Copy to Output Directory’ to ‘Copy Always’. The content of the file looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<connectionStrings>
       <add name="sql" connectionString="Server=<server>;Database=OfficeManager;User Id=<uid>;Password=<pwd>;" providerName="System.Data.SqlClient"/>
</connectionStrings>

The User ID and password have been hidden of course… The DAL has an additional class called AppSettingsReader.cs which looks like this:
using System;
using System.Configuration;

namespace DAL
{
    sealed class AppSettingsReader
    {
        public static ConnectionStringSettings GetConnectionSettings(String key)
        {
            return ConfigurationManager.ConnectionStrings[key];
        }
    }
}

For this to work there needs to be a reference to System.configuration in the project.

Wednesday, 24 April 2013

Step 2

In keeping with my previous post about attempting the work and then blogging about it afterwards, this post details what happened when I tried to point the existing app to the new installation of SQL Express...

In the VB6 world, my app had a single class that handled data access. A true single point of contact for the database. Everything was contained in it and to move to SQL would have been simple: Change the one class to communicate with SQL and off you go.

When I started the .NET port I tried to continue in the same way but quickly realised that it just didn’t work that way anymore. I didn’t understand the subtleties of .NET and so ended up using DataSets and TableAdapters in the form designer for each form that needed it. The project had a DataSet designer that graphically defined the links between the tables and so on.

Moving away from the Access database to SQL Server was therefore going to be tedious as there were numerous places that would need to be changed and then checked. But not to be put off I gave it a go!

First off, my Development Environment is contained in a Windows 7 Virtual PC, whereas I installed SQL Express on the main OS so I can use it for both Development and Production. So, fire up the VPC, load up Visual Studio 2010 and open the current project.

To ensure that I knew that during debugging there could be no way that data was being read from Access I renamed the Access database so that all data had to come from somewhere else (SQL hopefully).

Debugging the app threw an expected error “Could not find file 'C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb'.” Sweet.

Next, the connection string that was held in the settings file was changed from “Provider=Microsoft.ACE.OLEDB.12.0;Data Source="C:\Users\All Users\KCN\Office Manager\OfficeManager.accdb"” to “Provider=SQLOLEDB;Data Source=MainPC\SQLExpress;Initial Catalog=OfficeManager;User ID=sa;Password=<hidden>;

Debugging the app showed it didn’t work though! As the development environment was on a Virtual PC it was unable to connect to SQL Express on the host. Using this page I had to enable remote connections to SQL Express, enable TCP/IP, set the port to 1433 and then play with Windows Firewall to open ports 1433 and 1434 in both TCP/IP and UDP.


Finally a connection!

Opening the app and reading data worked fine, although the performance was PAINFULLY slow.

Testing a data write threw an immediate error of "Incorrect syntax near '`'." Hmmm. It quickly became obvious that it was never going to work as the SQL commands embedded in the DataSetDesigner were for Access and not SQL so things like "INSERT INTO `AssetTypes` (`AssetType`) VALUES (?)" are obviously going to fail.

I can see that there is no easy way to move the current app to SQL. I’m going to have to re-create the data schema in the application from scratch and then check every point of data access.

The question is this; is it worth all the additional effort?

Probably not. I think we'll chalk this one up as a failure and move on. I'll leave the current app as it is ...

Tuesday, 23 April 2013

Step 1

The current application is single user and was originally a VB6 application, so it makes sense that it uses a Microsoft Access database.
 
Not very 21st century though, huh?
 
The new version absolutely must use Microsoft SQL Server - there's no doubt in my mind about it, so to keep costs down I propose using SQL Express 2008 R2 to develop against.
 
Step 1 will be to download and install SQL Express, create a database with the same (or similar) data structure as the current database, and finally get some data into it.
 
The way I see it is that the starting point should be to port the existing application to use SQL Express rather than Access with no (obvious, or as little as possible) functional changes to the application resulting in a working product on SQL Express with the existing data. As time ticks by and the project progresses I will still need to use the existing application to run my business, and so the data will grow and change and I do not want to have any porting issues come switch-over day.
 
Anyway that's my rationale. So lets begin!

I downloaded SQL Express 2008 R2 With Tools from Microsoft and followed the installation procedure giving a named instance of SQLExpress and selecting Mixed Mode for authentication. Once that was done I fired up Management Studio and logged in to check things out.

So far so good.

Next was to port over the existing database from Microsoft Access. To do this I opened the existing database in Access and used the Uplift Wizard

 

 
I entered the settings for the new SQL Express installation and the new database name ...


... selected ALL tables ...


... accepted the default options ...


... selected "No application changes." as I want to manage the code changes myself when porting the current application to SQL Express ...


... and on the final step clicked Finish. The wizard threw up a few progress dialogues but nothing scary and in the end I was presented with an uplift report in Access.

I closed access and then used Management Studio to check the new database. It's all there! Excellent.

Step 1 is complete as I have a populated SQL database that I can use. On to step 2.