Featured Article(s)
Tips for using SQL Server 2005 Merge Replication (Part 2)
Here are some helpful tips to performance tune and optimize SQL Server 2005 Merge Replication.
I Can Hear the Users Now: "We Want (More) Reports!"
Egad. Building reports and writing the applications to produce them, get them to the users and let them tweak them with parameters and such is a super-time-consuming task, and one that never seems to go away. Just when you think you’ve built all the reports they could possibly need, a new request arrives. This has been the case for years on different projects I’ve worked with against SQL Server. With Crystal Reports, you can alleviate a huge chunk of this, giving users what they need, when they need it – let them do their own tweaking. Give them access to data on the web or in applications… it’s a solid solution to free up your day. Get more information here.
Legacy Applications
We’ve been answering the maintenance call with some legacy applications – we’re talking serious legacy here (at least in terms of SQL Server). These applications were built 6 or 7 years ago and have not been touched since being built and deployed. They’re used daily and definitely follow the "if it ain’t broke, don’t fix it" rule.
We’ve had a few of these crop up of late – people looking to standardize on a given database platform, are consolidating servers and this is forcing the need to upgrade these applications to the SQL Server version of choice. This means digging back through files, looking for sometimes non-existent documentation and trying to remember the weird quirky things that were done "way back when" to tweak and tune the applications…and that’s just for the applications we actually had a hand in.
Doing these same tasks for applications built by others, either internally to a business or through outside resources is an even more "interesting" task.
We’ve found that there’s a bit of a tipping point in time you take to document and make these applications "right" in terms of updated processing. We’ve focused heavily on a checklist of security sweeps (injection, cross-site scripting, etc.) and have begun to develop a bit of a best practices checklist that we follow along the way. We don’t go back through the code line-by-line, unless we’re forced to for the upgrade. This might be the case with custom DTS packages and the like, but generally speaking as long as the application doesn’t do funky stuff, it should work against the newer SQL Server releases.
I say all this because of two things.
1. Would you be interested in seeing the list of things that we’ve begun to distill in this process. The things that "make the grade" so to speak in a rational approach to upgrading these applications? I’d be happy to share it (and develop it based on feedback) if you think it would be helpful.
2. What types of things have you done in this area and where have you been finding yourself drawing the proverbial line in the sand as you balance the need to get a project done with doing it right?
Featured White Paper(s)
Are AJAX Applications Vulnerable to Hack Attacks?
This paper reviews AJAX technologies with specific reference to JavaScript and briefly documents the kinds of vulnerability c… (read more)
ESG Lab Validation Report of the HP PolyServe Database Utility for SQL Server
ESG Lab, the testing facility of industry analyst firm Enterprise Strategy Group, reports its comprehensive testing of HP’s s… (read more)
Migrate, Manage, Monitor: Top 10 Tips for a Successful Move to SQL Server 2005
Effective planning and management enables a smooth migration and ensures that your new SQL Server 2005 environment will be ru… (read more)