Run configurations

If I look under the PROPATH of the project, I only see the GUI PLs.  Likewise under the run configuration.

Ah, but the run configuration had Use TTY checked ... which is strange, because I deleted it and recreated it.

Since you seemed to do so well on that one, any idea why I am suddenly getting lots of

java.sql.SQLException:[DataDirect][OpenEdgeJDBC Driver]OE Broker fails to find a server available for connecting.

I also get no display in the Schema box.  In the past, I was getting this once and then it would continue just fine and the Schema would show up.  Now, though, its persisting.

Presumably, this has to do with the SQL connection for displaying the schema.  None of that has changed, of course. All that happened recently was I added an additional project with the same connection.

In the log, I see a bunch of

0: (8839)  No SQL servers are available.  Try again later.

So, apparently the issue is SQL access.

I have had vague counsel about adjusting the parameter for the number of servers and such (not really my area of specialty), but the surprising part to me is that this is occurring now when it didn't in the past.  This workspace does have 8 projects in it, 7 of which are OpenEdge, but 5 are closed so that only three OpenEdge projects are open.  I am sure I have done that tons of times before.  The Task Manager shows me 5 _mprosrv processes, one with a classpath argument, but all 5 with a DB connection to the DB I am using for all of them.  There is one _progress process.  The log seems to show three users still in and one that went in and out with the RUN.

I have no perfect answer, but there a few places to look.

I believe it means either the _sqlsrv.exe failed to start, possibly because of a port conflict, or you run out of user connections (as mentioned on PEG forum for the same question :) ).  Start by checking the database log file and see what gets reported there, maybe something failed to start.

Are you starting your database manually or are you letting PDS do it?  PDS doesn't tweak anything unless you put in extra startup parameters.  It just runs proserve -db <something> -S <something>.  That's pretty much it.  So if you have a few projects connected to same database (each one starts and AVM for compilation) and a few concurrent run configurations (each one also probably uses a DB connection), make sure -n and related is setup reasonably.  

If you are doing it manually, update your script to start _sqlsrv.exe with the port you want.

PDSOE use quite a few db connections and the default startup parameters will not suffice.

For your scenario, provided that you work alone, I would suggest:

-n 30 (or more)

-Mi 7 (or more, but not more than TRUNC(-n / 4).

Here is why:

Staring with the default parameters, you will have:

Total number of clients (-n) = 20

Maximum servers (-Mn) = 4

Minimum clients per server (-Mi) = 1

Maximum clients per server (-Ma) = 5, if -n is the default of 20. (By default -Ma = -n / -Mn)

So you can connect up to 20 clients - auxiliaries. Auxiliaries are connections like, BIW, APW, PROWDOG, promon, the servers and all secondary brokers. In a default startup max of 5 (PROWDOG and 4 servers).

Since -Mi = 1, a new server will be spawned for each of the first four client connections.  In a workspace with as little as four projects this can lead to 4 ABL servers and now the broker can't spawn a SQL server, since -Mn allows only four servers in total.

One connection per server is overkill in development environments. By increasing -Mi to 5 in your database startup parameters, it will not spawn another server of the same type until you have at least five connections to the existing one. Total connections will however still be limited to 20, leaving you with the ability to connect about 7 or 8 projects, unless you increase -n.

In short, I would suggest this:

-n = MAX( 20, 2 * Projects + 5 (for Auxiliaries) + Reserves),

-Mi = MAX(5, Projects), but not more that -Ma default

Projects = projects_in_all_workspaces_that_can_be_open_simultaneously.

Reserves = sessions needed for testing, e.g. when running the code or connecting AppServers, e.g. No of AppServers + (4 * no of developers) will allow each developer to simultaneously run four sessions connected to the database.

In your case:

-n = 2 * 7 + 4 + 5 Reserves = 23+

-Mi = 7 (22 / 4 = 5.75, so I would increase -n to at least 28 rather than decreasing -Mi)

Simon, thanks for some very concrete suggestions.  I am still curious about why I am encountering this now and I hadn't in the past.  It is *possible* that when I have had a similar number of projects in one workspace before that they haven't shared a database, but I would have thought so.

Looking promising ... took me a little while to find the right place to put them in, but it has now started without complaint and the parameters are set.  Now, all I have to do is fix my code ...

On the original problem, why did I have to uncheck run as TTY to get the assemblies to be recognized?  I thought batch & AppServer use of .NET was now OK.

So, I am running PSDOE 11.5 ... why should I have to uncheck run as TTY for a batch process that uses .NET?

Perhaps I have had multiple interacting issues and I will have to try going back and changing that now that I have the other aspects resolved.

I'm not really stuck on anything at this point, other than working out the bugs in my own code.  If I could go back to TTY, that might be better because the runs are fairly long when the work and that provides me with a visual signal that it is done.

OK, back being stuck.  I have been running with TTY unchecked in both the local and run configuration.  There are some errors in the code base I am compiling ... not the code I am running, but the code base I am compiling for analysis by ABL2DB ... which I thought might derive from TTY vs GUI.  So, I went and checked TTY again in both the project and the run configuration, recompiled all of the project code, and tried a run.  The run errors out with no message on the first line where it tries to invoke one of the Proparse .NET components.

Peter, the errors come in the code base I am analyzing, not the code in the project itself.  The code being analyzed is my old (ancient) Integrity/Solutions ERP package.  There is a bunch of crap in it so some errors are expected.  But, I also believe that some of the errors are only there when compiling as GUI.  Given that it is a ChUI application, that is not entirely surprising.  I am pretty sure that at an earlier point I was compiling with Use TTY and a bunch of these errors were not there.  But, this got unclicked during the transition to using Proparse, which I just recently added to the project.  The circumstances of that transition got muddy, so I'm not sure now what the actual problem was, but I got assured that I could go back to Use TTY.  When I noticed these GUI related compile errors, I switched back to Use TTY and now the application terminates on the first reference to a Proparse component.