Latest News

Is this the answer to the Progress -v- SQL Server debate ?

After the ongoing debate earlier this autumn on the respective merits of Microsoft SQL Server and Progress – and whether it was possible for the two platforms to co-exist, Andrew Bremner (the managing director of Focus IT Ltd) has been in touch to say “My company has recently been granted a license to sell and support a realtime Progress to SQL Server (or Oracle) tool in the UK. This tool is developed and owned by Bravepoint in the US. Called Pro2SQL, this is mature, stable and working at many Progress sites across the US. I believe this product has the potential to end the Progress -v- SQL Server debate and allow end users to have the best of both worlds with their production database on Progress and their reporting in SQL Server.”

He adds “Focus IT is licensed to sell, install, support and bill in GBP for Bravepoint's Pro2SQL suite in the UK. The agreement was signed 13th October 2009 so marketing materials like the website are still in their infancy. The product itself is not in its infancy though and replicates all Progress 9 and 10 data types into SQL Server 2005. A new version that will handle the new data types introduced in SQL Server 2008, like DateTime2 that handles dates before 1753, is currently in development and a release date will be issued in due course. Pro2SQL is aimed squarely at Progress sites that want near realtime/one way replication to a data warehouse or reporting database running on SQL Server or Oracle. The replicated database can be performance tuned for reporting without affecting the Progress production database.” +

Attached are a white paper and a marketing flyer.

9 replies on “Is this the answer to the Progress -v- SQL Server debate ?”

“that handles dates before 1753”
That's gotta be a clincher then. I know that this is the “first” date Microsoft recognises but to advertise a product saying “we can deal with dates from the 1600's” is not that great. I cannot think of any statute limitation dates that this would have any relevance to.

1753 wow I know myclients have wip issues but that's amazing. Does it have a guineas shillings and pence datatypes
Enter thy password

Unless the Progress developers have gone out of their way to add front end validation to their application to prevent mistyped dates going into the database, then most large Progress databases will undoubtedly have some dates before 1753 simply due to user typos. Subsequently, when transferring data from Progress to SQL either via replication or a batch dump & load, these invalid dates (only to SQL) cause the whole record to be rejected by SQL. I would consider any kind of data loss when moving data from one platform to another as a potential show stopper hence the point about these dates was raised i.e. the issue is recognised and solved.
Pro2SQL currently handles these invalid dates by changing the year on the offending value to 1753 so that SQL does not reject the record. This wont be an issue in the future when the product supports SQLs DateTime2 data type. There are other challenges solved in Pro2SQL like SQL's 8kb limit on char fields compared to 32kb for char fields in Progress, but in my experience it is the prevalence of mistyped dates that cause the issues.

CC writes… I was interested to know what the significance of 1753 was. According to a Google search, January 1, 1753 is the minimum date value for a datetime field in SQL Server due to it being the first full year after Britain adopted the Gregorian calendar.
Actually this feature could be relevant for Thomson Snell & Passmore, rated by the Guiness Book of Records as the UK's oldest law firm – although by 1753 they had already been in practice for 183 years.

The 8kb(ish) limit was a limit on the whole row before SQL 2008. From SQL 2008 the limits changed to individual fields for varchar, nchar, varbinary and sql_variant fields. The sum of the other column types in the row can still not exceed 8kb(ish) so that would include char and nchar.
Good article on MSDN to explain the differences:
The point is well made though. Even with SQL 2008 the difference between 8Kb and 32Kb is a large one to manage.

Could the significance of 1753 be linked to the messy adoption of the Gregorian Calendar? It all seems to have started in 1582 but the then British Empire didn't go for it until 1752.
Ot it could just be a coincidence that it's the year after “we” adopted the new calendar…

Or indeed other such pre 1753 illuminati such as Freshfields and the Bank Of England.

I agree but seriously here is a product that makes the process of going from something that is an anagram for the common name of Cyprinidae to sql easier. Which means you must have both Progress and SQL and this product to make the coexistance easier. Which begs the gob smacking stategic question of why not move to a product that support SQL and ditch Progress and forgo the coexistance pain.

This product is not simply about coexistence, its about getting the flexibility and best performance from two very different platforms. Sites choose Progress for many reasons, not least that the best product for them at the time was written on the platform. Also, Progress databases are relatively set and forget compared to the competition and I regularly come across sites (outside of the legal sector, which does exist!) running very stable and well performing systems with 400+ concurrent users on a 500GB database without any need for in-house Progress DBA support. Not many SQL or Oracle sites can boast that.
The negative perception of Progress aside, all sites that reach a certain volume of data have to face the fact that they cannot continue to run their reporting suite against their production database regardless of what platform it is on. Sooner or later, medium to large sites want/wish to move some of the reporting overhead hitting their live database to another platform. Not just that, they may also want to create a data warehouse or web database that hosts a subset of data from multiple systems, not just their live Progress environment. If the site is after something close to real time replication (not just a dump and load) then the platform for hosting this breakaway data set generally has to be the same as the live environment e.g. SQL to SQL replication via clustering or log shipping….or Progress to Progress via AI shipping or Fathom for Management. Not being an Oracle DBA I am not sure what the choices are there, but I suspect all real time replication technology is based on Oracle to Oracle. But what if the breakaway data set is part of a data warehouse accepting data from other platforms not on Progress or needs to be in SQL so the site can mount a website on it or leverage the SQL reporting tools they just inherited from their latest acquisition? For that matter, what about mergers and acquisitions that find themselves with a Progress and a SQL or Oracle platform…does the new head office forgo any centralised reporting until a lengthy and costly migration is complete?
My point is that there are lots of reasons why a site would want to replicate data from Progress to SQL, not just because Progress has fallen out of favour. Why migrate from Progress to SQL only to find that doesn't support high production & reporting volumes on the same database either when Pro2SQL can be setup in three days and costs a fraction of what it costs to migrate.

Comments are closed.