Question on -n setting

stanleytsui

New Member
We just recently migrated from Version 8 on HP-UX environment to OpenEdge 10.2A running on Red Hat Linux. We have 35 users license and have local, remote and connection from SQL server. Within the last 2 weeks that I monitored, we never have more than 35 users on the system at any one time. The -n value remain the same on couple databases as is what we have on Version 8. During mid morning, we will run into connection problem (error 5291), "You have attempted to connect to a database with too many users connected to it. Retry the connection later, or increase -n on the server."

We had been changing the -Mn, -Ma but come up with the same result. There is no way that we can increase the -n (already set as 64) value since we are on workgroup. Is there any way to work around this problem? It seems a bit unfair if the only way to resolve this is to upgrade to Enterprise so we can increase the -n pass 64.
 
That's the way it is - the workgroup database is limited to 64 connections and there's no other way around it as to upgrade to an enterprise database.

Keep in mind, not only does the workgroup database limit the number of connections, it is limited when it comes to performance and therefore it does make sense to limit the number of connections to not blow the database performance wise.

IMHO, the pricing policy of Progress products is anthoer story. But I guess that's what their sales reps are for ... aren't they?

Regards, RealHeavyDude.
 
If you really only have 35 users you shouldn't have a problem unless you're saying that every user has a local, a remote and a SQL connection. Post the actual parameter settings. There might be something odd. Also post the PROMON summary screen.
 
Not that this solves your original query as RHD pretty much covered the choices for increasing -n , but are you running prowdog on the database for disconnected users, etc? I'm pretty sure that in 10.2A it's still available for the workgroups environment (at least it was available in a few of the 10.x workgroup versions we have that I checked).
 
That's the way it is - the workgroup database is limited to 64 connections and there's no other way around it as to upgrade to an enterprise database.

Keep in mind, not only does the workgroup database limit the number of connections, it is limited when it comes to performance and therefore it does make sense to limit the number of connections to not blow the database performance wise.

IMHO, the pricing policy of Progress products is anthoer story. But I guess that's what their sales reps are for ... aren't they?

Regards, RealHeavyDude.


Thanks for the confirmation. Kind of know this will be the answer after some research these couple weeks, just need someone with more expertise to say this is it. Thanks again.
 
If you really only have 35 users you shouldn't have a problem unless you're saying that every user has a local, a remote and a SQL connection. Post the actual parameter settings. There might be something odd. Also post the PROMON summary screen.

Well. Our problem probably also related to some of the processes being written on the SQL side. It wasn't a problem on Version 8, but become a major issue on how they should behave in Version 10. We just try to avoid rewriting those as much as possible, Thanks.
 
Not that this solves your original query as RHD pretty much covered the choices for increasing -n , but are you running prowdog on the database for disconnected users, etc? I'm pretty sure that in 10.2A it's still available for the workgroups environment (at least it was available in a few of the 10.x workgroup versions we have that I checked).

I have to look into this. Thanks.
 
Sounds like a bit of auditing is in order. As Tom said, if there really are no more than 35 concurrent users, you should be OK unless you have multiple sessions per user in some way. That is discoverable. If you can understand why it is happening, then you will have a much better idea what you can and can't do about it. I don't believe there are any inherent differences between 8 and 10 which would account for this.
 
I think the problem we have is caused by the queries from our SQL side. This is something I noticed a few years ago. The programmer at that time wasn't doing a good job on his codes and was pounding Progress side too frequent too much. For some reason, it wasn't a real issue at that point of time. So, even it was pounding on the Progress side, we didn't pay much attention to rectify the problem. Once we moved onto Version 10, this problem seems to magnify. Too many short queries from SQL side taken over the connections to the database which allocate to SQL server and wasn't able to release back the unused one later to the 4GL side. We either have to clean up our act om the SQL side or move to Enterprise version. I really appreciate all the help and advise from follower members within such a short time. Learn a lot in this short 2 weeks just on this subject. Thanks.
 
In a scenario where both 4GL and SQL clients are connecting the database at the same time you need to have a secondary login broker set up. This way you provide a dedicated login broker to each type of client and the client spooling on the remote servers will work withtout a fuzz. If you don't you will exactly run into the problem you described.

You can query the knowldege base for "secondary login broker" and you will find entries explaining in detail how to set this up.

Regards, RealHeavyDude.
 
In a scenario where both 4GL and SQL clients are connecting the database at the same time you need to have a secondary login broker set up. This way you provide a dedicated login broker to each type of client and the client spooling on the remote servers will work withtout a fuzz. If you don't you will exactly run into the problem you described.

You can query the knowldege base for "secondary login broker" and you will find entries explaining in detail how to set this up.

Regards, RealHeavyDude.

Doing exactly that. I'm doing an audit to find out what will be the magic numbers should be to create a 2nd broker so I can specify the type of service for the broker. Hopefully, the situation will be improved. Thanks.
 
Back
Top