8.3 on Windows 2003 - also SQL-92 ODBC

[aYDee]

OK, I'm new to this, just need to find out a few things.

We have Progress 8.3 on Windows NT and need to extract data to an Oracle database. Will installing SQL-92 ODBC work with this configuration.

Also we are planning to upgrade to Windows server 2003, and have been advised to upgrade to Progress 9.2E as 8.3 will not work in Windows 2003 (which to me does not sound right)

What would be the most efficient way to extract the data from the progress database, all suggestions welcome.

All Progress development etc will be phased out by 2006, so additional database upgrades etc are not really necessary.

So my big question is:

1. Will Progress 8.3 work on Windows 2003

2. Will SQL-92 work with Progress 8.3

3. What other utilities do you recommend to extracting data from the progress database - keep in mind we do not have Progress skills or programmers on site.

Thanks in advance.

aYDee

 

[gcampbell]

If Progress states that 8.3 won't be supported on 2003 then listen to them. If anyone knows it will be them ...

And 8.3 is only SQL-89 compatible.

As for extraction of data .... is it a one-time thing or an on-going thing?

 

[aYDee]

Thanks for the reply, data will be extracted daily to an Oracle database, still have to figure out how this will be done.

Windows 2003 is just an upgrade to Windows 2000 - have to love how one is forced to upgrade.

SQL-89 on 8.3 and SQL-92 on 9.2 - these are our options - Win2003 only for the latter !

Considering that this particular system will be dead in 18 months, having to upgrade is not something we look forward to. When we move to a new system later on the data extracts to the data warehouse will just be redirected to the new system - which has yet to be determined.

OK, next question then, when we upgrade to 9.2, if we wish to use the conversion utilities, we will have to upgrade 8.3 to multi-volume before running the utility, otherwise we will have to create a new 9.2 database, and dump & load the schemas and data - not having a DBA or any skilled person on site, we may have to call in the experts in this regard. The database in question is less than 1GB

Once again, thanks for your help.

 

[gcampbell]

'just an upgrade' .... any upgrade cannot be taken lightly, IMHO. And I'm sure that drivers in 2003 work differently than 2000 etc etc. So it's not really an easy jump ....

Anyway, 8.3 isn't supported on 2003. Doesn't mean you can't try and run it. You may get lucky and have no issues ... then again, if you do 'just upgrade' and your database crashes, don't expect Progress to come to the rescue.
As for ODBC ... don't worry about it. Completely bypass this issue by creating a Progress batch procedure that will dump the appropriate records to a text file (on a nightly basis) then have another Oracle process load the text file accordingly.

 

[aYDee]

On researching the 2000 and 2003 differences I could not find a lot of info on the differences - much like NT and 2000.

We have the upgrade in our budget so it looks like it will go ahead if need be.

Creating a Progress batch procedure is not an option - we have no-one to develop or maintain it, and when we do switch to a new system these programs will not be of any use - can't reuse or anything.

We do use Informatica, may have to see if it can access the progress database directly via SQL-92.

Otherwise we may end up using VB or C to write the SQL extract scripts.

Maybe we should just stick to our NT box, install the SQL-89 driver and take it from there .... hmmm ... or we could upgrade to win-2000 which is a supported OS !!!

 

[gcampbell]

Well the choice is yours ....

SQL92 is not an option with 8.3 so you won't be able to access the DB unless you use SQL89. Maybe informatica supports that.

As for maintainability of code, how hard is this (substitute tablename with the name of your table:

OUTPUT TO c:\temp\myfile.txt.
FOR EACH <tablename> NO-LOCK:
EXPORT <tablename>.
END.
OUTPUT CLOSE.

If you need to filter on some data then just change the FOR EACH appropriately.

Doesn't get any easier than that ... and why try to hack a C or VB program together for handling this? Either way, it will also be 'gone' in 18 months.

Anway, enjoy ....

 

[aYDee]

The reason why we will not be using Progress 4gl is because no-one here knows or uses the language - if we use VB or 'C' or Informatica, we will be able to change the scripts when we switch to a different database - yes, there may be some changes, but the content will remain the same. We may even have to rewrite them completely, however the overriding factor in going this way is to have someone who is able to maintain the code - we do not get this with doing the development in Progress 4GL (we may even use java or Python) - what we use has to fit in with the goals and accepted IT practices of our company - the progress system is a legacy system from an acquisition and will not be supported. We nee a 'PULL' type solution and not a 'PUSH' based solution developed in legacy code.

Also, I need an answer on the best route to upgrade from 8.3 to 9.2 - use the utilities, or dump and reload into a new database - without the help of a DBA !

As always, thanks for the replies.

 

[gcampbell]

Why does it matter if you 'push' for now? As soon as your Progress system is retired where will you be 'pulling' the data from? And the new system may require changes anyway ... and it may not be accessible.

As for upgrading to v9, it's simple enough to run the conv89 utility (assuming you can convert the v8 DB to multi-volume).

One last thing though ... if you're trying to integrate with a Progress DB and you have no in-house expertise, I'd strongly suggest you get a local Progress consultant to help you out with this. Whether it be for helping you integrate or helping you upgrade. Things will go sooo much smoother .....

 

[jongpau]

Why does it matter if you 'push' for now? As soon as your Progress system is retired where will you be 'pulling' the data from? And the new system may require changes anyway ... and it may not be accessible.

Not to mention the fact that it will take only 10 lines of code or less to the export of table contents from within Progress. And even someone that has never seen or used Progress can easily learn and understand how to do that. Creating the "script" in Progress will only take an hour or so max for an inexperienced user, I bet someone that knows the 4GL does it in less than 10 minutes. Even better, most of the code that is required is already available in this thread so all that would have to be done is a copy and paste, insert the table name and maybe add a where clause...

Using a simple Progress procedure to do the export and one on the other side to load at your or your system's convenience would be a lot more cost effective than performing an upgrade to a system that is going to be "dead" anyway in a year and a half or so.
Besides that and assuming the Progress app is still in use; Depending how your Progress application has been created, you may encounter some nasty things. For instance: if some of the programs of your application use "words" that Progress has since added to the 4GL you will be in a lot of strife trying to fix things up. After the database conversion you will have to recompile your entire application and check whether or not any errors occurred and either fix these or update the keyword forget list. This means that you should always do a test upgrade before applying a new Progress version to your live environment. After the test upgrade you will also have to run through your entire application to make sure everything still works as it should. Only when you are certain everything works smoothly you should upgrade your live environment.

But, as said, the choice (and money) is yours

 

[aYDee]

Thanks for the advice guys.

Yes, we will be bringing in some Progress expertise to help with the conversion, as well as make some program changes.

I can see your point about using the 4GL utilities for the extract, I have over 10 years experience with Informix 4GL, and this is how I have always done my extracts.

Some good points to ponder. The only real concern is having no expertise in this regard - Once the extracts are in place someone within our company will have to take ownership of these scripts, will have to be responsible for any changes etc. The company is not going to invest in any Progress training, so we have to make do with what we have got. We have a pool of java programmers we can use as well as PL-SQL developers. Giving the DB schema to a java programmer and have them write the extract may seem like overkill, even unnecessary, but it may be the route we have to take.

Ideally, we would like to extract directly into an Oracle database.