Where can I find support for progress 6?

[smkarim]

Where can I find support for Progress 6 (RDBMS)?
I would like to find someone to answer the urgent questions I have in this area.
I am completely aware Progress 6 is very old, but I work in an office where they use a program developed using Progress 6.
Please help, I'm really desperate :-(

 

[RegiRobert]

I suppose the best resource are the V6 manuals.
If hou have specific questions about V6, maybe it's better to post the details on this forum.

 

[smkarim]

Thanks Man

Thank u for answering
Have u ever heard about Progress 6 working on two separate servers, but that can talk to each other? I mean, a DB is on one of the servers and the other server can send him requests and queries.
Cheers.

 

[RegiRobert]

Of course this will work fine.
The database was designed for remote access.

 

[smkarim]

Are u sure the remote access can be done by a server?

Do u know how to make this? I would be delighted to know.
Thank u again

 

[RegiRobert]

We have mostly used TCP/IP connections to our database.
Something like this should do the trick:
"CONNECT db-name -N TCP -H server-name -S service-name"

Of course, you have to start the database server first.
I suppose details about client connections and starting the db-server process can be found in the V6 manuals.

 

[smkarim]

I'd like to describe the problem in general:
We have a big application built with Progress 6. The program works on a Novell 4.11 network. It was implemented as a DOS application but now we launch it with WIN95 (_prowin).
We are currently reopening an office we had in a different location, and we would like the people in this remote office to have remote access to the database.
In the past, an additional server was deployed in the remote office, but the people who implemented this aren't working in the company anymore, they are out of reach and no documentation is available.
The network protocol was IPX/SPX but now we succeeded in turning it to TCP/IP on a client and on a secondary server.
We are thinking of creating a VPN between the offices, but have a bit of difficulties.
* Do u know a solution for this problem?
* Can u explain how we could connect two servers? Can this be done in the environment I described above?
* Should the CONNECT statement u mentioned be called when starting a remote server or when starting a remote client?
* Do u know any websites about progress 6? The Progress.com website doesn't contain sufficient info about this very old version.

Sorry for the long "quick reply".
Thank u very very very much for ur help.

 

[johnnebi]

There are no major differences in making remote connections between v9/v10 Progress and V6. All of the documentation for V9 is online at the Progress Website, but basically you need to:

- add an entry to your /etc/services file for each database you want to connect to . Simply create a service name/port number (that's not in use)

-When you start each database, specify the service with the -S and the hostname with the -H, and if necessary, the network with -N tcp

- When you start each client, in addition to specifying the db you want to connect to, specify the service with the -S and the host where the db is with the -H and if necessary, the network with -N tcp

It's that simple.

Cheers

 

[smkarim]

I guess something wasn't understood here
We would like two Servers to connect to the same database and each server to serve the clients in it's network.
The database is located at the first server only.
(Unless, wih "database" u mean server, johnnebi

 

[RegiRobert]

It's not possible having more then 1 db-server for a single db.
A solution could be to using multiple databses and synchronising them.
But this is the biggest overkill I can imagine.

 

[smkarim]

I see...
So I guess the only way is to make the clients in the remote office connect directly to the server which resides in the original office.
But... As far as I know, the performance would horrible since whenever a client sends a request to the db-server, the db-server returns the result INCLUDING THE GRAPHICS, and this means a lot of traffic.
Am I right?

 

[johnnebi]

Let's do a terminology sanity check:

• Server: The machine where the DB lives. Also know as "host"
• Broker: A Progress process running on the host or server that allows clients to access the DB
• Client: A Progress session (which can run on the host OR on a remote machine), that, through the broker process, is provided access to the database

You only need, and can only have, one broker for a database. All clients, regardless of where the reside, can access the database through that broker. You can have multiple DBs anywhere you like, each with its own broker process. A client can access all of these at the same time, thus enable the transfer of data between them.

 

[johnnebi]

Hey! my bullet points didn't show up!!

 

[smkarim]

Nice idea johnnebi
What do u say about what I described in the last post?
Can I avoid this by putting my *.r files at each client PC?

 

[johnnebi]

If you mean that standard client/server in a WAN environment sucks, you are right. Yes the r-code should be on the client machine.

 

[smkarim]

Does putting the r-code on the client machines solves the problem of the performance?

 

[johnnebi]

Well, unless the users are accessing some sort of share, where they have centralized access to one single body of r-code, it HAS to be installed on the client machine. But in either case, that's not the where performance hit is. The problem is the data. The client is maintaining a live, dedicated TCP connection. One by one, each database record has to be brought across the WAN for processing and then also sent back if there is an update. There is a lot of overhead with that.
If your app is a DOS UI, I would recommend putting it on a Unix box and providing telnet access to one centralized system. That would give good performance.

 

[smkarim]

The app runs on Novell netware 4.11
The clients were DOS at first but now they are windows apps. We use Windows 95.
The matter of the r-code is still not completely clear to me...
If the r-code is on the client, are the query and their results the only data which passes between the clients and the broker?
What about the graphics? How are they managed?

 

[JonMeecham]

Get your system owner to buy a second hand UNIX box. Put the database and all the code on that and use telnet (or similar) sessions to access the application.

Only screen information is sent over the WAN connection instead of all the db record information.

Jon

 

[johnnebi]

Define "windows app". Can u use a mouse?