Access to SQL Server migration … and Compatibility Issues !!

Recently I was involved in a migration project. Client was/is using ancient application built on Access 2.0 (yup … its 2.0) … I think it was started as a small app for just couple of users and with time it grew larger and soon it became mission critical application which still is built on old

SQL Server Views … gotcha while using sp_refreshview

Last week I blogged about use of Views in SQL Server. We also saw different types of view and best practices for designing new view and limitations that may prevent us creating a view too. As a part of best practice while designing we should always include keyword, WITH SCHEMABINDING which prevents any accidental changes

Oracle 11g R2 and Windows 7 … dealing with Enterprise Manager Troubles

So, this weekend I thought to refresh my experience with Oracle. And in that attempt, I decided to install latest of Oracle DBMS family, Oracle 11g. Now, it’s been a while since I used oracle, it was version 10g. And they have been significantly improved in version 11g, so I wanted to try them. But

SQL Server Views … to make sure others “view” what you want them to view !!!

In essence, SQL Server view can be considered as a “Virtual Table”. When we create a view, user “feel” no difference between it and a table. And we can query it exactly same way as we query any other table. View can be really handy when we are using some super complex query to get

SQL Server Installation Rules and “System Reboot Required” Error

When we do installation or removing SQL Server, it always executes installation rules. And what really weird is, installer even checks for these rules when we want to Un-install the SQL Server (kind of reminds me, my experience with Office ‘97 which had quite similar craving for installation media while uninstalling). Today, when we were

Database Normalization … taming the wild horse

For any application to use database and hence data effectively it is very important that data is organized properly. The most common problem for database is redundancy in data. If table has highly redundant data, that means for every operation (like insert, update or delete) it takes more effort to find correct record. And it