Where can I find support for progress 6?
- Thread starter smkarim
- Start date
This solution seems similar to the use of software like PCANYWHERE or a CITRIX server.
When we tried to use a PCANYWHERE connection between two clients (you know, one connected to the Broker using the Netware LAN, and the other client connected to it and controls it remotely). The results weren't so satisfying :-(
Plus, we had to have TWO PCS for each person!
Should the telnet session be faster than that?
When we tried to use a PCANYWHERE connection between two clients (you know, one connected to the Broker using the Netware LAN, and the other client connected to it and controls it remotely). The results weren't so satisfying :-(
Plus, we had to have TWO PCS for each person!
Should the telnet session be faster than that?
JonMeecham
Member
Just cause you can use a mouse doesnt make it a windows app.
I thought the first GUI version of Progress was v7.
Therefore it's probably a character app.
I thought the first GUI version of Progress was v7.
Therefore it's probably a character app.
JonMeecham
Member
Telnet to the unix box will be much faster.
Firstly, the unix box will do all the work.
There is no client server traffic at all.
Secondly, the telnet session is usually dual color ...e.g black and white, green and white etc.
Much less traffic for screen refresh information compared to 256+ colors in windows PC Anywhere.
(Also you dont need another PC at the other end to run PC Anywhere).
Firstly, the unix box will do all the work.
There is no client server traffic at all.
Secondly, the telnet session is usually dual color ...e.g black and white, green and white etc.
Much less traffic for screen refresh information compared to 256+ colors in windows PC Anywhere.
(Also you dont need another PC at the other end to run PC Anywhere).
I think the Unix solution is not suitable for us. First of all, it would make us return backwards more and more in time (Black and White screens, AAAHHHH!!!).
Secondly, we have some sort of word processor which is coupled with the Progress app, and we can't ignore it. This word processor can't run on Unix :-(
Maybe migrating to a newer version of Progress can solve our problem.
Secondly, we have some sort of word processor which is coupled with the Progress app, and we can't ignore it. This word processor can't run on Unix :-(
Maybe migrating to a newer version of Progress can solve our problem.
RegiRobert
New Member
...or, as an alternative, think about implementing Citrix for supporting remote sites
Hello, i am Yuval and I work with karim about our Progress problem.
Citrix\Pcanywhere will not work for us because of the slow link (128 Kbit) between the offices (i assume it will work for 2-3 users, but not more than that)
and telnet is too complicated because we need to re-write part of the Procedures for unix. (and our program has about 2500 procedures written 10 years ago)
We did some tests and one of them included sniffing the communication between the client and the server in normal operation, and the results was shocking: almost 800 KB (Bytes!) for 3 screens.
our theory is that progress work in this way:
1. client read .r file
2. client transmit .r file to the server without processing it.
3. server process the .r files and "fill" it with data.
4. server returns the entire screen to the cient.
5. client show the result.
Is our theory correct?
Anyway, after reading the post, i think that the best solution for us is to sync the 2 servers.
We can trust our link, and i can easily promise uptime of 99%, so our big problem is the sync.
How can we do it?
Can i run a specific procedure on every data update on the server?
How can i do this? can progress 6.2 process Global Events on the db?
we are plannig to upgrade anyway to a newer version of progress, and as far as i know, in the new versions of progress the DB server is an independent SQL server (MS, Oracle, etc...), so this is an optional solution, but an expensive one.
Please help us, we are trying to find a solution for more than a month and we cant see any Progress (ha
) on that problem.
Thanks
Yuval.
Citrix\Pcanywhere will not work for us because of the slow link (128 Kbit) between the offices (i assume it will work for 2-3 users, but not more than that)
and telnet is too complicated because we need to re-write part of the Procedures for unix. (and our program has about 2500 procedures written 10 years ago)
We did some tests and one of them included sniffing the communication between the client and the server in normal operation, and the results was shocking: almost 800 KB (Bytes!) for 3 screens.
our theory is that progress work in this way:
1. client read .r file
2. client transmit .r file to the server without processing it.
3. server process the .r files and "fill" it with data.
4. server returns the entire screen to the cient.
5. client show the result.
Is our theory correct?
Anyway, after reading the post, i think that the best solution for us is to sync the 2 servers.
We can trust our link, and i can easily promise uptime of 99%, so our big problem is the sync.
How can we do it?
Can i run a specific procedure on every data update on the server?
How can i do this? can progress 6.2 process Global Events on the db?
we are plannig to upgrade anyway to a newer version of progress, and as far as i know, in the new versions of progress the DB server is an independent SQL server (MS, Oracle, etc...), so this is an optional solution, but an expensive one.
Please help us, we are trying to find a solution for more than a month and we cant see any Progress (ha
) on that problem.Thanks
Yuval.
JonMeecham
Member
Your premise is incorrect
(assuming your using TCP/IP database CLIENT/SERVER connection):
1. If the .r files are located on the client the .r file information is not transferred anywhere, it is merely run on the client machine. If the .r files are located on the server the entire .r file information is sent across the network/WAN so that the client can run it. For a large application this will cause the network traffic to be high. If it is small, the client can be tuned so it keeps all the loaded programs in memory saving the need to keep reloading programs.
2. The client now has the .r in memory during its running. Each time it needs information it sends a request to that to the server.
E.g. FOR EACH customer: DISPLAY customer. END.
During each iteration, the client asks the server for the entire customer buffer so it can use it.
3. Each time the client pauses for input (e.g. UPDATE customer.credit-limit), there is no traffic between the client and the server. Once the update is done, the record set is sent across to network again.
Jon
NB This is a simplified "logical" description of what goes on; behind the scenes it's much more complicated.
(assuming your using TCP/IP database CLIENT/SERVER connection):
1. If the .r files are located on the client the .r file information is not transferred anywhere, it is merely run on the client machine. If the .r files are located on the server the entire .r file information is sent across the network/WAN so that the client can run it. For a large application this will cause the network traffic to be high. If it is small, the client can be tuned so it keeps all the loaded programs in memory saving the need to keep reloading programs.
2. The client now has the .r in memory during its running. Each time it needs information it sends a request to that to the server.
E.g. FOR EACH customer: DISPLAY customer. END.
During each iteration, the client asks the server for the entire customer buffer so it can use it.
3. Each time the client pauses for input (e.g. UPDATE customer.credit-limit), there is no traffic between the client and the server. Once the update is done, the record set is sent across to network again.
Jon
NB This is a simplified "logical" description of what goes on; behind the scenes it's much more complicated.
JonMeecham
Member
Regarding your second question about syncing:
Can both update the data?
If only one does updates, you can using after imaging (AI).
If both can do updates it can get very messy.
Can both update the data?
If only one does updates, you can using after imaging (AI).
If both can do updates it can get very messy.
I'm afraid both must do updates :-(
We are now seriously considering the move to a newer version of progress (9 or 10).
Do u know if the newest versions are backward compatible? starting to write the procedures again would be horrible...
On the other hand, how can we keep the precious data we have in our database? Can we dump and load it in a newer database? How complicated will this be?
We are now seriously considering the move to a newer version of progress (9 or 10).
Do u know if the newest versions are backward compatible? starting to write the procedures again would be horrible...
On the other hand, how can we keep the precious data we have in our database? Can we dump and load it in a newer database? How complicated will this be?
OK, i understand, and thank you for the explanation.
[*]Our tests were made while the .r files are on the client using TCP/IP.
[*]I still dont understand something: why it had to transfer 800 KB for 3 screens (pretty simple screens, by the way...)? well, after analayzing the traffic, we could see parts of the DB that wasnt supposed to be sent at all. can anyone explain this?
[*]Our application is extremely large and i dont think we can load 2500 procedures to the client memory, and i dont think we should, it will not help...
[*]It is bi-directional transfer (extending the office to another location...).
[*]I know it is complicated, but right now - it is the only thing we can do, isnt it?
[*]Like karim said, we are seriously planning to upgrade to a newer version of prgress, another big question - who takes care of the DB in progress 9/10? is there a multi-user engine, or an SQL server?
Thanks again for the help,
yuval
[*]Our tests were made while the .r files are on the client using TCP/IP.
[*]I still dont understand something: why it had to transfer 800 KB for 3 screens (pretty simple screens, by the way...)? well, after analayzing the traffic, we could see parts of the DB that wasnt supposed to be sent at all. can anyone explain this?
[*]Our application is extremely large and i dont think we can load 2500 procedures to the client memory, and i dont think we should, it will not help...
[*]It is bi-directional transfer (extending the office to another location...).
[*]I know it is complicated, but right now - it is the only thing we can do, isnt it?
[*]Like karim said, we are seriously planning to upgrade to a newer version of prgress, another big question - who takes care of the DB in progress 9/10? is there a multi-user engine, or an SQL server?
Thanks again for the help,
yuval
RegiRobert
New Member
A little remark: if Citrix is too slow, you can surely forget about real CS queries over a slow LAN...
RegiRobert
New Member
CS queries = Client/Server queries.
I mean that, if Citrix is too slow over a WAN, sending lots of data of the WAN will even be much, but really MUCH slower... or as I would say: only try this at home
I mean that, if Citrix is too slow over a WAN, sending lots of data of the WAN will even be much, but really MUCH slower... or as I would say: only try this at home
JonMeecham
Member
These forums are designed for guiders and pointers and emergency help.
You seem to be asking questions that would indicate you need to employ someone who actuall knows what they are doing.
Perhaps you should buy some Progress consultancy or employ an experienced contractor.
There are far too many issues in what you are trying to acheive to be able to answer them within these forums.
Jon
You seem to be asking questions that would indicate you need to employ someone who actuall knows what they are doing.
Perhaps you should buy some Progress consultancy or employ an experienced contractor.
There are far too many issues in what you are trying to acheive to be able to answer them within these forums.
Jon
I understand that Jon, but the problem is that we are really in a hurry(emergency) and because we live in a small state like israel, it's really difficult to find consulting in this area. Besides, I have already contacted Allegro Consultants (I don't know if they provide consulting here)by e-mail yesterday but still no answer.
That's why when we found people like u and regiRobert, we felt as if we have discovered a treasure
We are sure that when moving to a new Progress, we could solve the problem but we must know which components we have to buy in order to have an application running using the internet. Mainly, we must know if we can load our database in a new one, because otherwise we may move to something different from Progress.
We really appreciate ur help so so much.
That's why when we found people like u and regiRobert, we felt as if we have discovered a treasure
We are sure that when moving to a new Progress, we could solve the problem but we must know which components we have to buy in order to have an application running using the internet. Mainly, we must know if we can load our database in a new one, because otherwise we may move to something different from Progress.
We really appreciate ur help so so much.
Similar threads
- Locked
- Blogs
- Progress Blog
- Locked
- user22389296
- Stackoverflow tagged OpenEdge or Progress-4GL/DB
- Locked
- Joelle Andrews
- Progress Blog