Cross Join Progress Database via OpenEdge ODBC and PHP - php

Question

I currently have 2 ODBC connections set up on my web server. One that connects to the our enterprise QAD database and another that connects to our custom database used to extend our database. In this paticular example I have my employee records in the QAD database, and then an employee number in another table in the custom database.
Is there any way for me to set up a cross join between the two odbc connections in php so that I don't have to loop through the results of the first query and send several queries based on the returned results to tie my records together in a php array?
The best i've been able to come up with is to build an IN clause from my first query from our custom database, send the second query to the QAD database, and then do an array merge in php. However, this is an extremely slow process compared to a normal SQL join.

Answer 1

Not sure if you've already found a solution to this but there is a Progress article on how to do this.
Quick Guide To Setting Up MultiDatabase ODBC Connectivity
I had a similar requirement - I wanted to create a join between a table in the primary QAD database and a custom table in our custom database. I have tested this and it works well although my setup is slightly different. I needed to connect to QAD from Microsoft SSRS to create reports against the QAD data - I needed to create some reports that the standard QAD report designer could not handle.
I have tested this on Progress 10.1c (this method is only supported in 10.1b+).
So the steps I took were:
Create the oesql.properties config file as per the article relevant to the primary and custom databases.
Create the ODBC System DSN on the client machine (in my case a Windows Server 2008 R2 machine running SQL Server 2008 R2 with SSRS) with the additional database references as per the article.
Create a Linked Server in SQL Server via the ODBC DSN
Create a view which uses the OpenQuery syntax to extract data from QAD (in my case this was created in the ReportServer database) via the linked server.
Create standard T-SQL query using the view in point 3 as the data source. This was ultimately the datasource for my SSRS report.
I believe it is important that the bit versions of the OS/Database and the ODBC drivers match but haven't confirmed this yet.
Whilst my requirement is different to your's ultimately it's the QAD server config and ODBC setup that's key. As long as your PHP client can perform a similar capability in terms of the OpenQuery command then you may get this working. I don't have any experience with PHP so can't help you there.
It seems a bit convoluted but actually works very well and in a lot of cases actually outperforms querying data using QAD browses!
Hope this helps.
Edit:
Here's a sample of an OpenQuery command - you can see that the table joins work in the normal way but just require and additional piece in the table reference.
CREATE VIEW [dbo].[vQADData] AS SELECT * FROM OPENQUERY(LinkedServerName,
'
SELECT custTable.item_date AS DESP_DATE, so_mstr.so_site AS SITE, so_mstr.so_po AS PO_NO, so_mstr.so_inv_nbr AS INV_NO,
ad_mstr.ad_name AS ADNAME, ad_mstr.ad_city AS ADCITY, ad_mstr.ad_state AS ADSTATE
FROM customdbname.pub.customtable custTable
INNER JOIN pub.so_mstr ON so_mstr.so_nbr = custTable.so_nbr
INNER JOIN pub.ad_mstr ON ad_mstr.ad_addr = so_mstr.so_ship
INNER JOIN pub.sod_det ON sod_det.sod_nbr = custTable.so_nbr
WHERE so_mstr.so_site = ''SiteName'' AND so_mstr.so_shipvia = ''SHIPPER'' AND custTable.item_date IS NULL
')
Then just access the view using normal SQL syntax.
SELECT * FROM vQADData

Answer 2

Thanks to Tiran for his suggested solution. For those people that are trying to reference multiple tables via SQL server as Tiran was doing, I have additional input.
I'm trying to pull data from multiple sources (Progress), same table structure at the same time and insert it into our data warehouse (SQL Server). So I'm just trying to do a union of multiple same structured tables in different databases. Tiran's solution started me down that same path but the linking of Progress databases was a cumbersome process that required me to find a Progress DBA with 2-3 days free time (his quote) to put this together. When I spoke with people at Progress directly, they also pointed out that if I created a view with a union on the Progress side, it would sequentially extract the data from each source in the view, not simultaneously. However, this led me to another discovery that looks like it's going to solve our needs and totally skips dealing with linking tables on the Progress side.
Here's an example with three sources, same tables (this should work for cross source joined different tables as well). All names here are provided just for clarity in the examples.
Source 1 - Table_A
Source 2 - Table_A
Source 3 - Table_A
Create an ODBC connection to Source 1 named source1.
Create an ODBC connection to Source 2 named source2.
Create an ODBC connection to Source 3 named source3.
(Note, you typically want to be sure to set the connection setting to Read Uncommitted).
In SQL Server, create linked Server connections to each Source.
ls_source1
ls_source2
ls_source3
In your SQL Server database that you need to reference the Progress databases in, create a view joining the three different linked server connections together using a union. The linked server references will each need to use openquery. This example using select * from each linked server source presumes that all columns are named and structured the same from each source.
CREATE VIEW table_name_v as
SELECT *
FROM
(SELECT *
FROM OPENQUERY(ls_source1,
'select *
from source1.dbo.Table_A
')
union
SELECT *
FROM OPENQUERY(ls_source2,
'select *
from source2.dbo.Table_A
'
union
SELECT *
FROM OPENQUERY(ls_source3,
'select *
from source3.dbo.Table_A
'
)
) x
With the view created, you can now query all three tables in different Progress sources at the same time. No extra set up on the Progress side is necessary.
There is an important caveat that I'm currently working on a work-around for. If you are on a 64bit machine using 64bit SQL Server, you need to use a 64bit driver to connect to the Progress database with the linked server option. My needs require I have both the 32bit and 64bit drivers on the same machine and have run into issues with that as apparently they don't play nice together when on the same machine. I have been able to install both 64bit and 32bit drivers on the same machine (there was a glitch in Progress' website that was supposed to send me a link for that driver but I was able to get someone there to direct me to the correct place to retrieve the 64bit odbc driver. The average person should not need both drivers and can just use the 64bit. As an alternate work around, if I'm not able to get both drivers co-existing on the same machine, I've found and confirmed that the company Connx provides a driver that provides a 64bit/32bit bridge that resolves that issue for me. Ideally though, no third party software will be necessary.
A new issue has cropped up now unfortunately, as I the linked servers that I set up and were using are no longer functioning properly. Two steps forward, one step back....
Just thought I'd share my findings as I'm sure there are others looking.

Answer 3

Short Answer: You can't JOIN tables between two connections.
Scenarios: (all of them in one single connection)
By default, in most databases, you can Join tables in different schemas by prefixing the schema name before the table, like this:
(...) FROM defaultDB.TableA INNER JOIN extensionDB.TableA ON ({Condition}) (...)
Depending on your Database (I don't know about Progress DB deeply), you may not be able to join Tables that belongs to schemas in different servers.
Joining tables in different databases (Eg: Progress x MySQL) it's even more complicated. I've heard about Oracle Gateway, a proprietary solution that (not really sure) could achieve this last scenario.
In summary:
If your situation does not fit the first scenario (which points to the most obvious approach), I guess the shortest solution would be profiling your code and optimize possible performance bottlenecks. Adapting your code for parallel processing could be a bolder improvement.