Progress App sqlserver db

M

marymcmahon

New Member
Hi all, I have a progress character application (written in V5 and V6 using qbf! ) running on v9. The user now wants to rewrite the system in .net and use a sqlserver db. They want to keep the old system running while the new one is being written in phases. Someone suggested that they could convert the current progress db to a sql server db and continue to use the old app and develop the new app on the converted db. Therefore both systems will access the same data. Can this be done? Should it be done? All thoughts are welcome.

TIA.
 
Why not just wait for 10.1C next year and rewrite the UI in .NET?

But, to answer your question, yes, you can run ABL against SQL Server, but you would need the DataServer to do it and chances are that you would also have to do a certain amount of conversion to the existing application to account for the differences in database behavior.
 
A bit off topic, but I'm still wondering what is the great benefit of writing the .Net interface with progress.
  1. You still need progress client side
  2. .NET has much more capabilities then Progress can Handle (multithreading for example)
Casper.
 
Casper said:
A bit off topic, but I'm still wondering what is the great benefit of writing the .Net interface with progress.
  1. You still need progress client side
  2. .NET has much more capabilities then Progress can Handle (multithreading for example)
Casper.
Click to expand...
Indeed somewhat off-topic, but hey :)

I believe the main advantage would be that you can create a much richer UI than with what native Progress has to offer. You should be able (try to) "keep pace" with market trends in the area of UI design and functionality.

The way I understand it there will be two ways of creating a .Net UI with Progress:
- The one that's already here is the use of ProxyGen to generate proxies so you can call your appserver routines from within a .Net application. This means that you will need to have knowledge of for instance VB .Net or C# .Net. I have played around with this and it looks like it works ok, but I have not done any serious building yet though, maybe there are some people around that have. The really good thing of this approach would of course be that you can more easily integrate Progress and Microsoft functionality (think of accessing both Progress and SQL Server databases (or other databases through ODBC etc), the ability to create web services - which is still a bit of a pain in native Progress, easy access to MSMQ etc. On the other hand, all this beautiful stuff will only work on a Windows box, so if you want to write backgroud processes that can do some of this you cannot run them on Unix (and I am sure there are a lot more buts and ifs such as a lower performance due to the overhead of going through the proxy etc).

- The second, which will be coming in a future release of OpenEdge (I thought it was 10.2, but maybe it is indeed 10.1C) is that you can design the UI using .Net components directly from withing Progress. This will only work when you use OpenEdge Architect and, from what I was told at the conference here in Oz a while ago, you will be able to use both your old GUI UI windows/dialogs and newly designed .Net forms in the same application -- note you cannot mix these in the same window/form. In the background Progress will write some clever code that does all the interfacing for you and there will also be some "bridge" component that makes Progress talk to .Net. Good thing is of course that you don't have to worry about learning (or hiring people with) specific .Net skills, but on the other hand you will not have such easy access to the other goodies on an MS platform. Out of the box this will only give you the standard .Net controls. The nifty and good looking stuff you will still have to buy and yes, Progress will of course be reselling some of these (from Infragistics I believe). Now, I am not sure whether I heard this correctly, but I do remember hearing that Progress will ship it's own version of the .Net runtime and that it is based on .Net 1.0, BUT I may be completely and way off with that and just have been living in lala land during the session on this topic at the conference... Besides, it is quite a while before all this will be released and things are known to change

Paul
 
It starts to make sense if you believe that UI is just a small portion of the investment that you have made, or will make, in your application.

This is arguably true for most non-trivial business applications.

If you also believe that Progress 4GL is your best choice for writing "business logic" then the whole package makes sense.

If you do not believe those things then you probably shouldn't be wasting your time writing Progress code.
 
If you also believe that Progress 4GL is your best choice for writing "business logic" then the whole package makes sense.

If you do not believe those things then you probably shouldn't be wasting your time writing Progress code.
Click to expand...

I believe Progress 4GL is the best choice for writing BL but I don't believe that writing the UI with .NET components and 4GL is the way to go in a ditributed architecture.
But time will tell if this way of developing UI is more efficient then using two teams of developers (C# (UI) and ABL (BL)).

Regards,

Casper.
 
A bit off topic, but I'm still wondering what is the great benefit of writing the .Net interface with progress.
  1. You still need progress client side
  2. .NET has much more capabilities then Progress can Handle (multithreading for example)
Casper.
Click to expand...

.Net in Progress will be very useful for business like us who have a huge UI already in progress and can't rewrite it in a single stroke . It will permit us to rewrite part of it and use .Net controls for new windows without our clients having to buy a AppServer or have 2 Clients (one in progress and one in .Net for the same application).
 
I understand what you say. We where in the same position, but couldn't wait for this feature to proof it's value, so we started with building our own .NET interface. So now we have 2 teams of
developers one of them solely making UI in C# and the other team making the BL in ABL. This is surely a big bang scenario which is offcourse very risky in terms of investment and strict time-lines.

One advantage is that now there is a real strict border between UI and BL. Which makes the proces of making any type of Interface more clearly.
This can proof to be a challenge when you start redisigning your interface as well.

I must admit that is is tempting to make use of Progress to make a .NET interface and I hope for you that it is stable to work with and keeps sort of up-to-date with the development of .NET.


Regards,
Casper
 
You must log in or register to reply here.
Back
Top