Connect Windows appserver to a Linux database

[Clueless]

I have a working 11.7 openedge database on a Windows server. There is an appserver on the Windows server that connects to the Windows database that is working perfectly.

For "mostly political reasons", I am tasked with moving the Windows database from the Windows server to a Linux server.

So is this a "legitimate configuration"?

I plan on dumping the Windows data and definitions and load it into a Linux database.

I will start the Linux database with -S -N tcp, etc.

I will change the Windows appserver to point to the Linux server with -H <ip-address> -S <tcp/socket> .

So will the Windows appserver connect and execute code on the Linux database with just these modifications? - ie. no need to recompile the code that the Windows appserver is using to connect to the LINUX database whereas before it was connecting to a Windows database?

Will there be CRC errors or any other complications?

Help, I'm clueless...

 

[Rob Fitzpatrick]

So is this a "legitimate configuration"?

You and I may have differing opinions on "legitimacy", which is a value judgement, but this is a common and very acceptable configuration.

I will start the Linux database with -S -N tcp, etc.

At this point -N exists for backward compatibility. It doesn't hurt but it doesn't help. There is only one supported network protocol which is tcp. Specify -H as well. Note that these parameters are the bare functional minimum for client/server, but you should be specifying other broker parameters as well. That might already be in place in your case; I don't know.

I will change the Windows appserver to point to the Linux server with -H <ip-address> -S <tcp/socket> .

You can also use host names with -H and service names (from %windir%\system32\drivers\etc\services) with -S. Doing so allows for more generic configuration for disaster-recovery scenarios, e.g. failing the database over from your primary production server to your secondary (DR) server.

So will the Windows appserver connect and execute code on the Linux database with just these modifications? - ie. no need to recompile the code that the Windows appserver is using to connect to the LINUX database whereas before it was connecting to a Windows database?

Yes, assuming you correctly configure your database's 4GL login broker appropriately, which involves more than just -H and -S.

Will there be CRC errors or any other complications?

No. R-code CRCs are based on the schema (_Field and _File), and those will be the same between the old and new databases.

 

[Clueless]

Wow!

Thanks for the quick response!

One other consideration: What if the Windows Progress version does not match - ie. the Windows Progress is 11.6 or 11.5 whereas the Linux Progress version is 11.7? There are a number of these database moves and I'm not 100% all of them have Progress 11.7 - ie. there may be one or two 11.6 or 11.5s.

Since it is a network connection, I thought it shouldn't matter (major version?), but I can't remember the "rules of versions"...

 

[Clueless]

Oh, one other thing - will it help to use the -Mm parameter on the database startup to increase the packet size? or does that have any effect at all on appserver connections?

 

[Rob Fitzpatrick]

You're welcome.

The client OpenEdge release may be at or above the database release, up to one major-version different (e.g. 12.x client connecting to 11.x database), provided that the database connection is via TCP and not shared memory. The database release cannot be above the client release.

 

[Rob Fitzpatrick]

Oh, one other thing - will it help to use the -Mm parameter on the database startup to increase the packet size? or does that have any effect at all on appserver connections?

Yes, -Mm affects remote 4GL client connections. In 11.x the default value is 1024 which is quite low, and inadequate for most applications. Try 8192. You can specify it on the database login broker, and you don't have to specify it on the client (App Server) side.

 

[Clueless]

Thank you so much again!