Search results

Thanks Rob and Tom. I am definitely on 10.2BSP08, I'll open a support case. Thanks again.

Thank you all. Rob, I can't get it to work. Seems like the _userstatus table isn't being populated for some reason.

Thanks Tom, it is about 6gb. I got the code from the progress knowlegbase. I have OE replication, I don't want to have to re-baseline in order to do a dump and load into the new storage area. I tested it once and it took 30 mins, with a database not set up for replication, then I tested it...

I have tried doing a simple display of _UserStatus as well as this program I found from the knowledgebase, but neither work: /* display _userstatus VST for tablemove, indexmove, idxfix, idxcompact, idxanalys */ def var vName as char format "x(12)". def var vFound as log. repeat ...

Good morning, I have a 10.2bSP8 database on AIX and I need to move a table to a new storage area, I have tested it and it works fine but I want to be able to monitor the progress of the move so I can estimate when it will complete when I run this in production. I have seen from the progress...

Thank you Rob, I'll give this a try!

great, thank you

Hello, I am currently on OE 10.2bSP8 on AIX and I was going over my startup parameters and started thinking about my connections. I am monitoring for the -n parameter to ensure I don't get close to my max connections (-n 3280), however the majority of my connections are through my primary...

Tom, I agree. The problem is it's not entirely the vendors fault, our business unit says they don't have time to upgrade to the newer version of the application which would support newer versions of the DB. As for type of storage areas, they are Type 2.

No, I didn't perform a dump and load and no I didn't misreport the version. We definitely went from 10.0B to 10.1B, we are tied to the application and can only upgrade the database to the level that matches the application. Thanks

Hello! I recently upgraded from 10.0B to 10.1B (on AIX) and have had issues with the dbanalys report ever since. I think a lot of it has to do with the chain analys being added, I would only get information from some of the tables in the db and the index analys wouldn't give me any...

Actually there is a good reason. When we purchased our application we got progress, we get support for our database through the application company not Progress, and since the application is tied so tightly with the database the application dictates what version of progress we can be on, and...

Thanks Tom, we are actually upgrading this weekend to 10.1B. And I did figure out I can use root to shut down the db.

I am getting the following error: SHUT 139: User progress cannot disconnect user xxxxxxxxx. (2258) I am using the proper user to do the disconnect, it is the user that created the database and the user that starts the database. It seems to have started happening out of nowhere, we use this...

Hey Tom, the -Mi is actually set to 4, I guess we should revisit that.

Thanks again Tom! Sergio, I'm not 100% sure how many users, the business units are adding contractors we were unaware of, and we thought the -n 961 was good but obviously it wasn't, we want to have room for at least another 100 users.

Thanks Tom, yes it is multiple brokers. So something like -n 1200 -Mn 261 -Mpb 240 -Ma 5 Would be good? Second broker has an Mpb of 20.

Sorry, it's a little urgent for me obviously not for anyone else. I got the following error today on my Production OpenEdge 10.0B database: 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. (5291) I know...

Thanks, I did and I see absolutely nothing strange in the .lg file except that some users logged in and then out almost immediately.

OpenEdge version 10.0B on AIX. I got a call saying some users could not log into the application. All I see is where the user id tried to login and then immediately logged out, no error messages at all. They do not get the message "Userid is now xxxx", it is exactly like this: Login usernum...