Progress DB 4GL and ODBC data extract - odbc

I am trying to connect to Progress DB 4GL to extract data using ODBC (Qlikview).
Is is possible to extract data using 4GL via ODBC?
Can you please guide me on this?
Thanks and Regards,
Silambarasan

You can use the included ODBC driver but that uses SQL syntax, not ABL (4GL) queries.
Progress Datadirect has a product that offers an ODBC frontend for OpenEdge Appserver https://documentation.progress.com/output/DataDirect/openaccessbooks/oaoeguide.pdf
http://acorn.ro/products/abl-jdbc/ offers a jdbc interface to ABL code.

ODBC clients talk SQL, not 4GL.
To use the 4GL to extract data you use either a "self service" (shared memory) connection if you are on the same host as the server, or you can use a "client networking" license if you are on a network connected computer.
You could, of course, go through all sorts of convoluted stuff to use the 4GL without an actual db connection and a series of intermediate layers to somehow get an ODBC data connection. (You could, for instance, use sockets to communicate with a C# app that uses ODBC to connect to Progress...) But the specifics would depend on what you have available, what your coding skills are and why you are trying to do this.
If you were to manage to cobble together something like that you would still have the problem that the ODBC connection speaks SQL. So if you are expecting features like 4GL index selection or triggers or "variable width data everywhere" to work you are going to be out of luck. The SQL interface is ignorant of those things and won't be able to provide them.
I'm pretty sure that Clikview doesn't talk 4GL at all -- so you would also have to convert from 4GL back to SQL again. The whole thing makes no real sense.
(Regarding "why" I can only imagine that you are attempting to bypass a licensing requirement. If that is the case then you are not only making this much, much more difficult than it needs to be but you are also not going to solve the licensing problem. The license doesn't care what technologies and products are, or are not, used to make connections.)

As far as I know, you can use the Progress SQL92 interface via ODBC to access 4GL tables (CRUD for records), but you cannot create or amend 4GL tables using SQL92.
Any tables you create using SQL92 CREATE TABLE command, cannot be seen by 4GL/ABL programs.
The Progress website says that the Progress ODBC driver is included in the Progress/Openedge client package.

Related

ODBC driver for HBase/Phoenix

I need to connect Tableau to HBase or Phoenix and Tableau does not support JDBC. Bummer!
I've read about the proprietary Simba driver but haven't seen any reports of people using it. I don't feel like forking over money when it's not ideal, and my employer feels the same way.
Is there another way to connect Tableau to HBase or Phoenix? How are other people doing it? I don't like the idea of using Hive to connect to HBase because one of the main reasons to go away from Hive is its atrocious performance, so I hope that's not my 'best' alternative.
On the other hand, if people have used Simba and it works well, I'm curious to hear about that.
I am the developer on Simba's Phoenix driver. Hortonworks, Cloudera, Databricks, Microsoft, Amazon, Google, etc all choose Simba's drivers for a variety of products.
ie. http://hortonworks.com/partner/simba/,
http://www.simba.com/news/databricks-offers-simba-technologies-developed-odbc-3-8-connectivity-sql-capability-apache-spark/
Also, you need to choose either Phoenix on HBase or HBase standalone for all of your applications. The two types of drivers encode data in different binary representations. String and unsigned integers will be interpreted correctly, but unsigned integers and more complex data-types will be decoded differently.
ie. Phoenix doesn't display negative integer values correctly
So if you use Phoenix JDBC for your / applications, you cannot use an HBase ODBC driver with Tableau (unless you have nothing but strings and unsigned integers in your datasource). From your other postings, you do use Phoenix JDBC. So HBase ODBC is not an option for you.
The CData ODBC driver will allow you to connect Tableau to HBase (full disclosure: I work for CData Software). You can download a free Beta here. We have an article that outlines the configuration and connection, but I've copied the relevant information steps:
Create/configure a DSN from the ODBC Driver by setting the server address and port (we use the REST API, so the default port is 8080)
You should click the "Test Connection" button in the DSN Configuration wizard to ensure that you can establish a proper connection to your HBase database.
Click through the "Connect to Data" options to find "Other Database (ODBC)" and select the DSN you configured
Select CData as the database
Enter a Table name (or leave the Table field blank and click search (the magnifying glass) to see a list of Tables).
Once you have access to the tables, you can work with them exactly as you would any other table in Tableau (drag the table to the join area, manipulate Measures and Dimensions to view your data, etc.). If you have any questions, I or our Support Team will be happy to help.

How to use ODBC to connect to any DBMS

I'm developping a java application and i'm using JDBC to connect to MySQL Database, now i want to use ODBC to be able to get and retrieve data from any DBMS, of course if have access to it. Is there an API or tool to do this ?
What you are looking for is a JDBC-ODBC bridge. There are several available. It is not recommended, instead you should always use a native JDBC driver.

Should you use ODBC or Registry Entry for data connections?

I support a group of developers that are telling me to setup a registry entry for an application that they made in asp.net to connect to our SQL backend. Would it not be better to do this from an ODBC connection? Is this lazy programming or is this common practice?
If all their connections are in registry entries how will I be able to spin up the DRP site in case we have an issue? Right now we replicate the content across and it would be a heck of a lot easier if the DB connections were in ODBC instead of having to redo all these registry entries. (there are multiple apps doing this).
Please fill me in. Thanks
Why are they not using the web.config to store connection strings? http://msdn.microsoft.com/en-us/library/ms178411.aspx

Is there a Microsoft Exchange ODBC Driver?

I want to be able to query an Exchange address book via ODBC. It seems like there ought to be a driver available for this puprose but I can't find one.
MS Access can link the Exchange table, and I can then query the Access database via ODBC, but it is pitifully slow.
For the record, I'm not programming so I don't need ADO connection strings or whathaveyou. The database software I'm using (Drawbase, a space database for facilities management) needs an ODBC system data source so I need an ODBC appropriate driver so I can create one.
There is one here:
http://www.connect-gate.com/index.php/en/why-connect-gate/sql-for-communication
It's quite fast and cover the most important SQL statements.
I've done a fair amount of ODBC work and also run Exchange and I've never heard of one. :(
CData seems to provide the driver now: https://www.cdata.com/drivers/exchange/odbc/ - not sure if this is the same as the Connect Gate driver above or not.

can postgresql scale to the likes of sql server? is it easy to tune?

hoping someone has experience with both sql server and postgresql.
Between the two db's, which one is easier to scale?
Is creating a read only db that mirrors the main db easier/harder than sql server?
Seeing as sql server can get $$, I really want to look into postgresql.
Also, are the db access libraries written well for an asp.net application?
(please no comments on: do you need the scale, worry about scaling later, and don't optimize until you have scaling issues...I just want to learn from a theoretical standpoint thanks!)
Currently, setting up a read-only replica is probably easier with SQL Server. There's a lot of work going on to get hot standby and streaming replication part of the next release, though.
Regarding scaling, people are using PostgreSQL with massive databases. Skype uses PostgreSQL, and Yahoo has something based on PostgreSQL with several petabyte in it.
I've used Postgresql with C# and ASP.Net 2.0 and used the db provider from devart:
http://www.devart.com/dotconnect/postgresql/
The visual designer has a few teething difficulties but the connectivity was fine.
I have only used SQL Server and not much PostgreSQL, so I can only answer for SQL Server.
When scaling out SQL Server you have a couple of options. You can use peer to peer replication between databases, or you can have secondary read-only DB(s) as you mention. The last option is relatively straight-forward to set up using database mirroring or log shipping. Database mirroring also gives you the benefit of automatic switchover on primary DB failure. For an overview, look here:
http://www.microsoft.com/sql/howtobuy/passive-server-failover-support.mspx
http://technet.microsoft.com/en-us/library/cc917680.aspx
http://blogs.technet.com/josebda/archive/2009/04/02/sql-server-2008-database-mirroring.aspx
As for licensing, you only need a license for the standby server if it is actively used for serving queries - you do not need one for a pure standby server.
If you are serious, you can set up a failover cluster with a SAN for storage, but that is not really a load balancing setup in itself.
Here are some links on the general scale up/out topic:
http://www.microsoft.com/sqlserver/2008/en/us/wp-sql-2008-performance-scale.aspx
http://msdn.microsoft.com/en-us/library/aa479364.aspx
ASP.NET Libraries are obviously very well written for SQL Server, but I would believe there exists good alternatives for PostgreSQL as well.

Resources