Cannot connect to PDSOE database server

Posted by dbeavon on 18-Apr-2016 09:06

I have my PDSOE installed on a VM ("VMA") that is dedicated to Progress/OE tooling.  And I have .Net -related development tools installed on a VM for .Net ("VMB").

My .Net apps can remotely connect to all my appserver stuff on "VMA".  Those brokers (state-reset and state-free) are running via adminserver on the "VMA".

But when my .Net apps try making SQL92 connections to the database (for some read-only reports) they always fail.

Please help me understand what I need to do to complete my "VMA" PDSOE installation so that I can move forward some client/server development.  Is it true that there will be some additional licensing $$$ involved?  I thought the development database server supported 4 concurrent users or such?  Is there a local/remote restriction?  Is there a supported approach for developing with PDSOE where I can actually connect to the database?  (It seems that when I remote into VMA and use Eclipse to connect to "localhost", that works.)

I'd prefer a solution where we don't spend an excessive amount for me to connect to my own development database from my .Net apps.

All Replies

Posted by Brian K. Maher on 18-Apr-2016 09:10

What OE products do you have installed on VMA?

Posted by dbeavon on 18-Apr-2016 09:16

It is only PDSOE at this point, IE

Progress DevStudioforOE            ####      11.6     #####16 OE 11.6 FF   Windows 32bit      Serial #:    ######  Rel: 11.6    Control#:########     Unit Type: Registered Client      

Posted by Brian K. Maher on 18-Apr-2016 09:22

Not 100% certain but I expect you need some kind of DB license on VMA so that you can start DB servers which allow remote connections.  Right now you have development AppServers running with local database connections to them and these AppServers can be accessed remotely (which is why things work).
Get a DB license installed, start the servers on a port and see what happens.

Posted by Brian K. Maher on 18-Apr-2016 09:36

One other thought ... try starting a secondary login broker just for the SQL connections and see if that works for you.

Posted by egarcia on 18-Apr-2016 09:37


If you only have Progress Developer Studio, you most likely would get a message like the following when starting a database server with network parameter -S:

10:18:50 BROKER  0: This server is licensed for local logins only. (4393)

As Brian mentioned above, you would need a DB license that allows remote connections.


Posted by dbeavon on 18-Apr-2016 10:04

Thanks for the tips.  Assuming I need a "DB license" , and the one in PDSOE isn't a sufficient DB license for client/server (SQL92) reports, what do I need to call our Progress rep and ask for?  Again, I'd be looking for the least costly option since the PDSOE database license seems to meet my purposes, aside from disallowing the SQL92 client connections.

(We already own enterprise RDBMS licenses but they are in the HP-UX platform - on IA64.  However, I'd like to do all of my local PDSOE development work in win32 if possible.  It prevents me from having to schedule database downtime for schema changes and what-not.).

Posted by Brian K. Maher on 18-Apr-2016 10:10

workgroup database, but ask your rep if there is a developer license which includes minimal capabilities for remote sql connections into it.

Posted by dbeavon on 19-Apr-2016 08:03

Quick follow-up.  I tried the secondary broker and it still prevents connections with anything other than "localhost".  For example, even on the same machine (vma) I cannot connect using the machine name.


proserve lumbertrack -n 70 -Mn 10 -Mpb 4 -Ma 10 -Mi 3 -S 9000 -minport 9001 -maxport 9004 -ServerType 4GL -PendConnTime 30

proserve lumbertrack -m3 -Mpb 5 -Ma 5 -Mi 5 -S 5001 -minport 8001 -maxport 8005 -ServerType SQL

Posted by Brian K. Maher on 19-Apr-2016 08:12

Then you will need to database license which allows remote connections.

Posted by on 19-Apr-2016 11:14

This is expected behaviour for ‘development’ database… the vma is not the same machine in that regard but you might get along with port forwarding between host and vma (only if you use NAT not bridged mode) -

Marian Edu

Acorn IT 
+40 740 036 212

Posted by dbeavon on 19-Apr-2016 15:51

Thanks for the tip.  I'd be surprised if the port forwarding would work.  I'd probably have to mess with the forwarding of both the server port (-S) and the ephemeral range (-minport -maxport).    Besides I don't want to break the terms of service.  I'm sure if Progress was on board with this, they would have made it easier.

Software development work is complex these days, eg. from an infrastructure standpoint, (ie. software can be configured for cloud, client-server, multiple application tiers, etc).  

I have to say I'm a bit annoyed that Progress makes my job harder and more complicated than it needs to be.  For Progress to restrict SQL92-based access to a dev database server from another (dev) machine seems like they are out of touch.  Maybe connecting to a dev database from a remote machine used to be an "extra"/"bonus"/"enterprise" feature.  But these days it is common for apps to be built using a number of tiers, and deployed in the same fashion.  All of our .Net stuff runs on 2 or 3 tiers, even in development.

Is there a document that explains all the PDSOE license restrictions (vs "development" licensing compared to "enterprise")?  I would have liked more of this type of information before configuring my PDSOE vm ("VMA").

Posted by Rob Fitzpatrick on 19-Apr-2016 16:15

Your question is valid.  My first thought was that product components and sub-components are documented in the Installation and Configuration manual (and they are), but does that contain the detail you need?  I'm not sure.  I see sub-components for PDSOE like "Database Server", "Progress Databases", and "4GL Database".  I don't know specifically how these things are defined but they aren't meaningful to me and they don't distinguish between RDBMS products (Personal vs. Workgroup vs. Enterprise)

I know that PDSOE and OE Studio both include the Personal RDBMS license, but *how* do I know that -- from a faded memory of reading the docs or from learning the hard way?  I suspect it's the latter.

Maybe this is covered better in some KB article, but that's not where it belongs in my opinion.

Posted by Brian K. Maher on 20-Apr-2016 05:12

Keep in mind that “we” don’t know that a machine is a dev machine.  From a software perspective, a machine is just a machine.

This thread is closed