How to use to 2 DBs with the same name on the different servers?

W

wesadex

New Member
Beginners question - I need some help:

I have 2 databases named g3 (both) on two progress-servers (9.1E and 10.1B). I know how to connect to db, f.e.:
Code: 
CONNECT("db.pf")
but don't know how to use these databases in code. How will compiler know what DB I wanna use in f.e.
Code: 
FOR EACH g3.table1 ...
? And how to use each of DBs separately in one module?

Thanks for answers!
 
You need to use two different logical database names. The ABL references always work on the logical database name which you can specify in your connect parameter file.

Heavy Regards, RealHeavyDude.
 
You can give the databases different logical names when you start a session (or CONNECT) with "-ld logicalName".
 
Thanks! I'll try.

Doesn't work. "Database has wrong version number" error occured. How can I fix it? No way?

I execute on 9.1E server:
Code: 
CONNECT "msk.pf".
IF CONNECTED ("mskg3") THEN message "Yep" VIEW-AS ALERT-BOX INFO.
ELSE message "Nop!" VIEW-AS ALERT-BOX INFO.

msk.pf:
Code: 
-H 10.0.0.50
-db /home/g3/db/g3
-ld mskg3
-d dmy
-yy 1950
 
Your msk.pf file is odd: It contains the -H parameter (IP host address) but it does not contain the -S parameter (IP port number). Therefore I suspect you are doing a shared memory connection and the -H parameter is ignored. If that's the case the Progress version under which the client and the database are running must match up to the patch level.

As that is not the case you must use a remote connection supplying the -S and -H parameters. Plus you client must run with the highest version which in you case would be OE10.1b.

Heavy Regards, RealHeavyDude.
 
Thanks. Unfortunately I need to use 10.1B db from modules running on 9.1E - not on the contrary. I see it's impossible.
 
That is not entirely correct. You cannot directly connect from a 9.1E client to the OE10.1B database. The reason for that being that the OE database meta schema has changed dramatically ( new data types like BLOB, CLOB, INT64 & DATETIME for example ). But, you can connect from a 9.1E client to the OE10.1B AppServer connected to a OE10.1B database as the AppServer protocol has not changed. So it is not impossible but you need to buy the AppServer license and a developer license in order to be able to compile your code under OE10.1B ( if you don't already have one ). Another option ( but I would not advise you to go down that route ... ) is developing a program in a language that supports ODBC or JDBC connections ...

Heavy Regards, RealHeavyDude.
 
Thank you for advise! Connection to AppServer is the way but it was replaced in remote network with very slow connection to both servers. Can I set up another one AppServer connected to 10.1B database (exclusively for 9.1E-to-10.1B connection)? I have all needed licenses.
And one more question about ODBC: as I know to use ODBC connection from f.e. C++ application I need to have ODBC driver for progress database. Is it available for download anywhere or I need to bye special license/software for it? Two or three years ago I couldn't find where download it. And what is the reason for you not advise me to use this way?

I ask all these questions because I need to reorganize some global structure that consists of modules and projects written on many different programming languages (4GL, c++, Object Pascal and even php) and uses many database types (MS SQL, MySQL, Progress) into one global project that will be able to use all this databases on three continents. This is the greatest work and so I wanna know and need to use all available ways.

Thank you one more time for your help!
 
I don't fully understand
but it was replaced in remote network with very slow connection to both servers
Click to expand...
- what does that exactly mean? If I would speculate I would guess that the AppServer instances were not connected as self-service clients via shared memory directly to the database ( such a connection is only possible if the AppServer and the database are located on the same machine and are running under the same Progress/OpenEdge version ) - which is the preferred way to connect an AppServer to the database and by that completely bypassing the network layer and its limits.

You can configure and run as much AppServer instances as you like and you can dedicate an AppServer instance to only execute a selected set of procedures ( have a look at the EXPORT function ).

As for the ODBC/JDBC drivers: They are included in every Progress/OpenEdge runtime license and you can download them from the ESD ( you should have an account on the ESD - if not you need to contact your Progress sales rep ).

Heavy Regards, RealHeavyDude.
 
Excuse me. English isn't my native language and still isn't good enough. Unfortunately, I didn't develop and design our network. AppServer connects to 10.1B database server through VPN-connection and this VPN-connection is very slow. I don't understand who really made that and what for.

About AppServers I'll read documentation - thank you. ODBC drivers I'll download from the ESD - thank you too.
 
Just my 2 cents: For security reasons it might be reasonable to separate the AppServer and the databases they connect on distinct machines. It might also be reasonable to do that for fault tolerance or load balancing on the AppServers. Performance wise it is best to have them on the same machine and let the AppServers connect via shared memory ( as self-service clients ) to the database, unless, your setup is so large that one machine can't handle the load. But why somebody would set up a VPN tunnel to connect the AppServers to the database when none of these machines is located outside the intranet eludes me. Could it be that everybody needs to suffer for somebody paranoia?

Heavy Regards, RealHeavyDude.
 
No. There are no security reasons for that in our company. It's just the stupidity. Head of software developers and network administrator that were fired some months ago want to do nothing. Unfortunately it's evident! Separating of AppServer and Database Server is good idea for load balancing because we have two types of 4gl applications - one of them are graphical (they use frame widgets, window widgets, colors, mouse, smart objects etc. - AppServer) and another ones that only use frames in terminal version of our system on some clients (those use direct connection to DB server). But the reason for separating App and DB servers using this slow VPN-connection is very simple: time for opening graphical application on clients in the remote network (they only use that AppServer) was very large in case if AppServer was located in the same physical network as DB servers. I really know it. Now I need to write from scratch those modules. Our network is closed for remote access despite the fact that all of our hosts located in one logical network - 10.0.0.0/8. All what's important now are the speed of data access everywhere and the ability for access certain needed data at the certain clients.

But I understand your reasons and will use them in my work. Thank you one more time!

p.s. Is my English good enough for you to understand me?
 
The reason for separating App and DB servers using this slow VPN-connection is very simple: time for opening graphical application on clients in the remote network (they only use that AppServer) was very large in case if AppServer was located in the same physical network as DB servers.
Click to expand...

If true this is very, very strange.

The opposite should be true -- it should always be faster for the app server to be close to the db -- preferably using a shared memory connection on the same server.

There are, of course, plenty of ways to misconfigure a system and make it behave badly. Perhaps something like that was done here?
 
TomBascom said:
it should always be faster for the app server to be close to the db
Click to expand...

Remote applications before showing GUI to users confirm some data from DB. This is the reason for large start-time.:( There are really many many ways to misconfigure system. I see this everywhere. :(
 
You must log in or register to reply here.
Back
Top