I hate Crystal Reports

Crystal Reports is touted as an end-user reporting tool.
Then it requires the entry of sql in it’s own twisted format.
Developers end up using a dumbed down tool.

One of the products that I work with uses Crystal Reports as a data transformation tool.
This app parses structured messages to load it’s database.
Crystal is then used to query this database to produce a report that is fed back into the application.

We have upgraded the product recently and it has updated Crystal.  The new version has lost the ability to resize the page.  You need to use the printer setup to set the print size.  Oh and the existing data has been badly squashed up to fit into an A4 page.

I am exporting data as a text file.
Yes I am using a report WYSIWYG screen painted tool to define fixed with text output.
The app then uses a pick screen to identify fields to read in.

Adding WPF and WCF to VS2005

Microsoft as I have said before are not very good at writing installers.
They have a tendancy to ignore possible futures and always test for exact current versions.

This is the case when you try and add the WPF and WCF addons to VS2005.

Here
is an article on how to make it work once you have installed service pack 1 for .NET 3.0

The idiot who wrote the installer tested for the presense of the uninstall option for the initial version of .NET 3.0, ignoring the possibility of a service pack.

This is not the first time I have seen a microsoft installer perform this stupidity.
Back in the day I learnt a lot about the registry configuration for COM objects the hard way.
The 16 bit version of VB installed a common library.   Subsequently this library had a 32 bit version released too.
If you installed the 16 bit version over the 32 bit one it clobbered the registry sufficiently to break the later version.
Rather inconsiderately the application suite that I was assisting used both versions…
I had to write a patch utility to correct this problem.  COM always had a technique for handling this kind of versioning problem but it was clear that whoever wrote the installer did not understand this.

How to escape the microsoft viral marketing campaign

When Microsoft release a new version of office that has an incompatible file format all of the users have been recruited into a viral marketing campaign.  This is especially the case with the new docx format.  The receipent may need to upgrade their wordprocessor to read the document.  Given that recent versions of office only run on recent operating systems this could force a machine upgrade – a little steep for no real benefit.

This is especially insideous when combined with the default setting of hide known file extensions.  Users don’t even know that they are using the new format until someone receives the document and can’t read it.  This is a wonderful drain on productivity and the novice user that has just bought their new machine does not understand how to “save as a doc file”.

Now I can understand a file format change if there is a real benefit to the user (say Excel 2007 now allowing more than about 50k Rows) but for a majority of the world this is not of use.

Here are some links to means of setting the old format as a default:

http://www.creativetechs.com/iq/save_word_2008_files_as_doc_instead_of_docx.html

 

http://technet.microsoft.com/en-us/library/cc178949.aspx

How not to add features.

At work I have recently got a new machine and it came with XP (it does have a Vista sticker on it so must be relatively recent).  This is where I encountered one of the annoying new features of XP: Search is broken.  When you search for a file only known file types are searched.  So the data files that I receive from an automated feed that are identified by a sequential file extension are silently ignored.

According to the following KB article this is a feature not a bug.
The claim is that by limiting searches to known file types the searches will be faster.
Faster yes, but also pointless as the files that I am actually searching for are ignored.
This should have been controlled by a simple registry setting with the default being the existing windows 2000 behaviour.

It appears that the drone that designed, coded and tested this has never actually worked outside of a software house.
Big hint: the real world has far more file types than those known by microsoft!

Learning from the DBA

In most places that I have been the SQL experts have been mostly self taught.
This has oftern left me being the most experienced SQL ‘expert’ on the team.

I am lucky at my current position to have a real Sybase expert around.
I am learning more about tuning stored procedures from him than I have in years of experimentation.

In the past I had avoided using temporary tables in sprocs as they only seemed to cause problems.
Now I am seeing temp tables in almost every procedure.
What would have been a join with a complex OR clause can be better implemented as a pair of insert statements plus a delete.  This can allow the use of an index for all of the select.

Another key point is to always be explicit about creating temporary tables.  Never use insert into #table to create the table.  This locks the temp db and can impact other users or reduce concurrency in the database.

The following construct looked wierd as part of a join:

col_b = Isnull(col_a, NULL)


Why would you replace a NULL value with a NULL?
Apparently in Sybase this converts the NULL into a comparable type so that NULL equals NULL.
However if this is used on both sides of the join:

IsNull(col_b, NULL) = IsNull(col_a, NULL)

Then this is a means of not allowing the column to be used in an index – which can ensure that the correct index is chosen!

Another construct that I had not seen before was using an update statement to populate a local variable:

        update MYTABLE
          set   REP_VERSION = @NewVersion,
                STATUS_IND  = ‘A’,
                @OldVersion = VERSION
          where MY_REF   = @Ref
            and STATUS_IND = ‘R’

This can lead to some highly efficient code – there is only one trip to the filesystem where normally there would have been two.

Use of these techniques alone has reduced the runtime of one set of sprocs that are run daily from 30 mins to 90s.
Give these are run concurrently with some oher time critical sprocs this is a big win.

The Purpose of Software Architecture

A recent task at work involved me reusing a technique that I had used approximately 10 years earlier (reuse of a form with a tightly coupled UI without displaying it).  This has got me thinking back about the various software projects that I have worked on over the years.

The first time I encountered an application with a strong architecture it was a bit of a shock to my system.  It slowed down my development since I had to solve the problem in the manner that would fit the architecture rather than however I felt like (which had been my previous experience).  Once I was familiar with the system my productivity was restored (other than the crazy manual version control process) and the fact that the system had three sub architectures depending upon the module that you were working in.

The purpose of software architecture is to make an application seem as if it has a single consistent author and design.  This speeds future development as a new developer (or user) only has to be shown one part of the system and the rest should behave (where possible) in the same manner. 

The opposite of this is where an application has no architecture and each screen could have been written by a different developer with no reference to their co-workers.  This makes enhancements more difficult as you need to work out the what and how of the screen/module.

Oh and by the way architectures are designed, not architected.

Piecemeal Deployment

There have been a lot of arguments about the relative benefits and costs of using stored procedures versus making direct inline sql calls.

The argument used to be that stord procs were faster (less sent across the wire from client to server plus precompiled results).  This is less the case these days with better caching technology in the databases.

Another argument is the security one.  If the application only allows the end users to call the sprocs then there is a much smaller surface area to attack/abuse.  If the users can call sql directly it only takes one technical user to start making direct calls from excel (or another freely available client tool) and one user can cripple server performance with a careless query.

Sprocs also make a great place to put business logic that needs to be identical across multiple client applications – especially if they don’t share a codebase (At work we have an inhouse app and an extensible third party application that need to call the same code).

Sprocs also make for very clean bugfix deployment.  Since you can freely replace it in a single place (per site intallation) this makes for a low cost option – compared to an application rollout which could affect hundreds/thousands of machines.

I wonder if that is the real attraction of a web application development.  You can freely replace a page without kicking out all of the users (at least that is the attraction of PHP – not sure that asp.net allows that much flexibility).