bring up progress database read only?

dschuchman

New Member
is it possible to bring up a progress database read only when doing multi user mode?
(hoping there is a -RO option that can be giving to proserve)

i know you can connect to a database read only with the -RO option, but what if you need to have the progress database up in server mode(using proserve)

looking for a way to make sure no updates occur in my database that's up in server mode.
 
No.

Except that, using Fathom Replication (now OpenEdge Replication) you can create a target db that is read-only. But there is no way to do that with a stand-alone db.
 
I am bit confused when you say NO upates to the database when brought up in Server Mode. If you dont want any updates to be made to the database they why not issue a proquiet <db> enable when you bring up the database.

Arshad
 
sounds like proquiet would wait for all updates to be made.
is there a way to tell proquiet to fail if any updates are made(instead of waiting)?
 
Ok, I thought about it ;)

The main reason that people want a -RO db with a server is so that you can have -B. Or run multi-user against a db on read-only media like a CD or DVD. But in practice -RO without a server is pretty close performance-wise.

The other issue with -RO is roll-forward. If you have a reporting db that has been built from a backup plus ai files you cannot start a server with losing the ability to roll-forward. A read-only server mode would, presumably, not have this problem. The proquiet approach would not, however, fix that :-( (starting the server would still mark the db as having been opened). And such a mode would not magically make it possible to apply ai files and have the server know about the changes.

Nor would it help you start a server against a db on read-only media.

So, in short, proquieting a db and leaving it that way is an interesting idea but I don't think it has a practical use. Unless I'm missing something?
 
I will just try to play around with my test database(network) and see that if it is really possible.Will try to figure out if there is any way to ensure that if there is any way for the updates to fail rather than waiting for it.


Arshad
 
Well As Tom said earlier enabling proquiet will not be a practical solution this leads to performnace issues where the screen just freezes when running under proquiet enabled.

Tom would it be possible to make the form greyed out(view-as text) if it meets a particualr condition.

What I was thinking that we will bring up the database normally and use a specific .pf to bring up the client session. we will identify this pf through session value and if found we will assign a true value to a logical variable and make it PVAR(persistent Variable). If variable true then make the form non-editable. But we have to insert this condition in all the update screens. Also this will fail if we make any update through webspeed brokers as this check will be there only in the user interface.


Arshad
 
I'm a bit confused -- why do you need to have a server running? Are there other sessions which are not read-only?

It seems like you want a read-only database in order to enforce a read-only session on particular users.

Of course maybe the problem is that I'm no longer sure who "you" is and what the requirements are ;) So I'll just blather into the ether...

That's what -RO does -- it makes your session read-only. Of course there are some downsides to that. Little things like your session crashing if the data that you are reading changes. So it would be nice if -RO actually connected to shared memory and was aware of changes...

One way to acheive this might be to use -RO in conjunction with a client/server session. Something like:

mpro -H localhost -S myService -RO -p test.p

Of course your session will still crash if it attempts to lock or update records. But it would have the ability to see a more consistent view of the data. I'm not sure if the client session will bother checking for updates once it has read a record. The behavior of -rereadnolock might, for instance, be impacted.
 
Back
Top