_dbconng.r giving errors

[Cringer]

I've got an application that uses _dbconng.r (from the ADEComm pl) to prompt a user for a db to connect. When I try and connect to it as a self service client I get
---------------------------
Error (Press HELP to view stack trace)
---------------------------
Unable to attach shared memory Global\sharemem.e.database.live.icmasliv.0, error 0. (1720)

-db 'E:\Database\Live\ICMASLIV.db' -dt PROGRESS -ld 'icmashome'
---------------------------
OK Help
---------------------------

The error is reported by _dbconng.r.

Struggling to work out what the problem is. Any ideas?

Progress 11.2.1

I also have the ability to use a pf to connect the db and that works fine.

 

[TomBascom]

http://knowledgebase.progress.com/articles/Article/P92479

 

[Cringer]

Thanks Tom - yes found that link and went through all the options and it's all fine from that end.

 

[Cringer]

Am I maybe using the wrong piece of code? When I try and connect to the db from the AppBuilder it's working fine.

 

[TomBascom]

Write a little stub program that does the CONNECT and have your application use that. If it works then the issue would seem to be with _dbconng.r Otherwise it has something to do with how the session is connecting.

Aside from what the kbase said issues with CONNECT inside a session are often related to permissions. Especially when shared memory connections are involved. Try connecting with -H & -S and see it that makes it go away.

Or... are you sure you want to be connecting via shared memory in the first place? Is the session that fails on a remote client? Does the .pf that works have -H & -S in it?

 

[Cringer]

Connecting via shared memory works fine. In the pf I've just set -db and -ld - so self-service and that works. When I try and self service it in _dbconng it still seems to be trying to use shared memory. Very odd.

 

[TomBascom]

That's not odd -- if you're connecting self-service it should be using shared memory. That's normal. Does it work to connect client/server?

Restart your databases with "-shmsegsize 128". That might help.

 

[Cringer]

Duh yeah got my head in a twist there
Sorry - client/server works fine. Self-service doesn't.

 

[Cringer]

shmsegsize is currently 1024 according to my logfile. Which option is it in the blasted OE Management? Wish they told you what each option equated to

 

[Cringer]

Hmmm shmsegsize set to 128 and all is fine with the world. Thanks Tom.

 

[TomBascom]

OE Management is not on my approved tool list. You might think that that is because it requires the use of a mouse and you would not be wrong. But it is also because actually finding and changing the options that you need is an exercise in frustration and futility. Quite possibly because the properties files are such a fuster-cluck of an abomination. Plus it makes it so darned easy to hose everything beyond repair.

Just say NO to OE Management.

 

[Cringer]

There's not a huge amount of choice in a Windows environment. Yes you can go scripted for the dbs, so long as you remember to start your APW and BIW services too. But you still need the admin service for appservers etc, so you have to configure them in the .properties files and there's not nice and easy tool for editing them at all.
I agree OE Management is a pile of poop. And it's an area that needs some serious focus. But sometimes you just don't have a choice.

 

[TomBascom]

I find that:

proenv> write conmgr.properties

Works much better than OE Management.

Scripting is very simple with dbman, asbman etc.

Also -- put as many parameters as possible into .pf files and refer to those .pf files from the properties files. That way you don't have to pay much attention to editing the properties.