I have been looking at parts of SQL Server 2005 since the June CTP and been implementing SQL 2005 in production and development environments since December last year.  The difference between investigating the features and doing an implementation is that in an actual implementation you use the most practical and useful features, rather than the cool features that you may use one day in some future architecture.

SQL Server Reporting services is cool and useful - but is a separate bundled package - so I consider it a new product, not a new feature.  Similarly with SQL Server Integration Services - a great step in the direction of visual programming and DSL's (Domain Specific Languages).  Other features are intriguing and I intend to put them to use on some future architecture; the Service Broker, Database Mirroring and CLR Integration are some of the features that pique my interest.

Currently there are two things that I used immediately and so extensively that I almost can’t imagine what it was like developing for SQL Server a few months ago – those two are Schemas and Error Handling.  I would have to say that the addition of try-catch block has made the biggest difference.

T-SQL is often viewed as a second-rate language compared to C#, Java or other modern (or at least Object Oriented) languages.  However the set-based bias of T-SQL has always meant that a lot of functionality can be developed in stored procedures – some would argue too much.  The addition of the try-catch block brings T-SQL closer to being a more elegant and usable language.  Handling errors, particularly within the scope of transactions was difficult and cumbersome prior to SQL2005 – the need to inspect @@ERROR after every statement meant that the code was either riddled with too many error checks and conditional statements to exit elegantly or had insufficient error handling that would leave data in an inconsistent state.

Although not necessarily a candidate for a ‘best practice’ award, I have a chunk of boilerplate code that I put in virtually every stored procedure – allowing me to handle errors gracefully and to roll back transactions.  This code even reports the exact line number that an error occurred (including errors that occur in triggers or nested stored procedures)

BEGIN TRANSACTION

BEGIN TRY

  -- Do stuff

END TRY

BEGIN CATCH

  IF @@TRANCOUNT > 0

    ROLLBACK TRANSACTION

  DECLARE @ErrorMessage nvarchar(4000)

  DECLARE @ErrorSeverity int

  DECLARE @ErrorState int

  SELECT

      @ErrorMessage = N'Error in '+ERROR_PROCEDURE()+N' (Line '+CAST(ERROR_LINE() AS nvarchar(20))+N') : '+ERROR_MESSAGE(),

      @ErrorSeverity = 1,

      @ErrorState = ERROR_STATE()

  RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState)

END CATCH

IF @@TRANCOUNT > 0

  COMMIT TRANSACTION

It may not look like much and there are far more sophisticated uses of exception handling, but putting the above code into your stored procedures will increase the quality of your code and the integrity of your database by orders of magnitude for virtually no effort.

Simon Munro

Virtually every architect has wrestled with problem of where to put ‘Business Logic’ and as technology changes and matures I doubt there will ever be a correct answer.  The rules stating that ‘business logic’ should always go here or there are stated by people who would only be able to depict application architecture with a set of crayons and a colouring-in book.   I have seen applications where none of the 'business logic' is in the database and a whole lot of wrapper classes do everything that a database would do (such as enforce foreign key constraints) - to the other extreme where virtually the entire application is developed in the database.  As with everything in software architecture, you need to weigh the pros and cons that are specific to your application.  So some pointers:

• Define what you mean by 'Business Logic' - this means many different things to different people and it is a good idea to establish some sort of baseline.  One could argue that tables in the database, by virtue of the fact that they represent business semantics, are in fact business logic.  Generally 'Business Logic' refers to some sort of procedural programming, but you would be well advised to define, agree and document what functions your business logic performs.  You will probably find that 'business logic' spans all layers and technologies - you have to understand what type of business logic goes where.
• RDBMS's do perform some 'business logic' incredibly fast and it would be pointless to try and 'roll your own' mechanism in another layer.  Things that are best left to the database include enforcing referential integrity, ensuring primary keys are unique etc.
• Most native database languages (by this I refer to PL/SQL & T-SQL - not Java or .NET in the database) execute extremely fast and almost always faster than an external language.  There are some cases that you can see a performance benefit in external applications, but this is usually for bulk operations where plenty memory is available - where you can suck lots of data out, work with it in memory and dump records into the database in one go.  As a .NET or Java developer, you will almost always lose an argument if performance is an issue.
• Database vendors are trying to turn their databases into application servers and referring to 'the Oracle database' actually refers to more than just the RDBMS.  SQL2005 has a 'Database Engine' (the RDBMS) as well as 'Reporting Services', 'Integration Services' etc. which, although bundled with the database are not really part of the RDBMS.  So when assessing the 'extended' functionality that is offered such as providing 'Business Object Services' out of the database, think carefully that this is not the core of the database and the suitability of the database platform for providing the architectural framework needs to be assessed as if it was any other (non-database) technology.  My favourite example is a database 'feature' of being able to send email from within database stored procedures; not RDBMS functionality at all!  Obviously database vendors want to sell more product and create tie-in to their platform, particularly Oracle who uses the well establish RDBMS brand to punt the rest of their products - be wary of database vendor marketing material.
• On the newer database platforms you can run Java or .NET code that is executed by the database.  This is useful in some cases but mostly it is unnecessary because the native languages a frikkin' fast by comparison as the engine has been coded up over the years with them in mind, and the set-based paradigm that we are used to in database languages doesn't translate all that well with more object oriented constructs.  Mostly you would use this for accessing some external functionality.  Also, the database has less control over these types of applications and badly coded .NET or Java on the database server can bring it to its knees.  In SQL2005 the CLR actually runs inside the SQL memory space and processes and is managed by the database engine - allowing the database itself to prioritise, allocate memory or even kill rogue tasks in order to satisfy the real RDBMS operations that are being performed.  I know that Oracle9i spawned off JVM's that were in control of the OS, not the database - I don't know if this has changed in 10g.
• Lastly - make sure that you are consistent in where you put business logic.  Often the biggest problem is that in one module a type of business logic is in one place and in and in another module it is elsewhere making it difficult to maintain, debug and migrate.  Wherever you decide to put the business logic (or parts of it), make sure that it is consistent across the project.

This question has been around for a long time and will there will never be an answer that applies across the board.  Like everything in systems architecture, you have to look at the specifics of your project to come up with the best approach.

Simon Munro

Last months' announcement by the Borland CEO that they are getting out of the IDE business makes one of the loudest statements about Delphi in a long time.  Depending on who you speak to it is the final nail in the coffin, a interesting footnote on an already dead product, or to the minority - a good thing for Delphi.  Whatever you think it means, I doubt that Delphi will ever return to it's 90's glory days.

A more relevant question than 'What happened to Delphi?' is: 'Why is www.delphi.co.za hosting a blog where an individual is going on about non-Delphi stuff?'

So let me try and answer that question.

I used Delphi from v1 to v7 (the last 'good' Delphi) and built much of my professional career on Delphi.  Mark Shuttleworth, who because of the gazillions of dollars (pounds or whatever) he has, can advocate the use of open source as much as he likes - he never has to work again.  I could be an all out Delphi developer; but for commercial reasons it is just not possible - I just don't have the kind of cash the Mark Shuttleworth does.  While Delphi may be used in some niche markets, in the area they I work in - data-centric business applications - if you are not developing in .NET or Java it is virtually impossible to find regular work at a reasonable income.

It becomes particularly difficult when working at the architectural level.  For some reason people belive that Delphi is a non-Microsoft platform, when Delphi actually has always been at the bleeding edge of Microsoft technology.  I remember developing apps that ran on SQL Server 4.21 on Windows NT 3.1 (on a 486DX266!).  In 1995, on a Borland roadshow, I demonstrated Delphi creating ActiveX controls - the only other tool at the time was VC++ (I think VB was still in version 4).  It was also around that time that the first data-aware TreeViews became available - something that development tools are still struggling with.  I was on a team where we wrote complex multi-tier applications with DCOM at the height of that fashion. On the web I used Delphi to create super-fast ISAPI DLL's before ASP was even on the market.  Delphi was the Microsoft development tool of choice for those who didn't have the patience for MFC and couldn't stand the data-crippled flicker-infested applications that came from VB.  For some reason though, Delphi (and it's cousin C++ Builder) were soldiers in a non-existent battle of Windows compilers - when the real battle was for the server platform where .NET, Java and others were striking blows.

Most of the good Delphi developers that I have worked with have found a home in .NET - it is commercially viable and has some nuances of the VCL that have probably seeped through from Anders Helsberg - the original Delphi architect and now the creator of C#.  I, like many of those developers still use Delphi often - although we seldom admit it to others.  I still have a fully functional Delphi environment with all the Developer Express components and can snap together a data-aware application faster than any other tool.

Delphi still has a place in the market and many good tools out there use Delphi.  The Skype windows client is developed in Delphi and so are TOAD and PL/SQL Developer - the essential tools in any Oracle developers toolbox.  Delphi was a leader in development architecture - Windows functionality (as mentioned above); the best tool for data-aware applications; the only tool with decent grid controls thanks to Developer Express; one of the first to practically implement the concept of a disconnected data set (TClientDataSet); quick off the mark with DCOM and Web Services; implementation of the concept of a data source (1993) - something .NET is only now getting around to.  The list goes on and every Delphi developer will be able to list their favourites.

Delphi succeeded despite Borland's pathetic marketing - the tool was so superior that the developer community simply used it; not because it was well marketed.  Delphi even survived the Inprise debacle but was, already then, becoming sidelined.  Borland then decided that the future of Delphi was .NET, which is really just Pascal for .NET  - yet another obsure language that supports the platform.  Whoever made that decision forgot that Delphi's strengh was always the compiler and the VCL - by going the .NET route you lose both; leaving behind an outdated IDE... which is now being dumped.

Delphi will still have a place in my personal toolbox and will always be remembered as a platform that I enjoyed developing on and had great success with.  However, my migration to .NET was not the Delphi route and I see no future for Delphi on the Windows platform as the outdated compiler fails to support Windows Vista.

The announcement has no effect on me professionally or commercially... it only has an emotional effect as I am forced to read the writing that has been on the wall for a while.

Simon Munro

Welcome to delphi.co.za

As with many websites, the lack of meaningful content within an existing structure results in a website that stagnates to a point that even the owner loses interest.

I am undertaking this blog as a challenge to produce some worthwhile content in the areas that I work and think in.  Hopefully, soon this blog entry will slide down the page into the archives.

Simon Munro