You'd need something like database replication, but this would require another copy of the database to be hosted on a server that writes to the SAN.
Or you would need to mirror the partition that the database resides on, on to the SAN. Although this might have performance implications.
We are using Storage Areas for different tables, plus some indexes have there own. We’ve done all the normal file system block for Progress block size stuff, even change the record block count on Storage Areas to optimise our internal block usage. This is all this sitting on a nice beefy RAID1/0...
I’ve developed code with Progress for 10 years starting at version 6. I love the easy nature of the code in V6 it was a true 4GL. Now if you use any of the Dynamic Code capabilities of Progress you are really using a GL3. It’s possible to write Progress code that will compile, but will generate...
Here's something that will sort of do what you want... just update output everything... I use this to reconcile two DB's schemas in a while you can show to developers.
&SCOPED-DEFINE MAINDB DB1_name
&SCOPED-DEFINE SECONDDB DB2_name
DEF VAR cv_answer AS CHAR NO-UNDO.
DEF VAR lv_i AS INT...
Here's a piece of code that might do something close to what you want... but I don't promise anything.
/*Process Each Area of the DB*/
FOR EACH _AreaStatus
NO-LOCK:
/*Set the variables*/
ASSIGN iv_LastExtentSize = 0
lv_OnLastExtent = NO.
/*Used to find all the area information like...
I’ve been doing some searching around this site and have found the following:
A reference to Progress KB: 20566 that’s been quite helpful. Well in figuring out a good size for my BI Clusters. Its recommended checkpoint time is 120 seconds, while the DB currently has an average of 18 second...
I hoping somebody out there would have a rule of thumb for BI Size. I under the size of this file has little to do with the actual size of the DB and all to do with the amount of updates & new data writes. Does anybody have a way to guestimate the size of a BI file? I’m sure there must be...
You should always use Procdures for Database modification as Functions don't handle RETURN ERROR correctly. Meaning you can't undo transactions correctly if you have a Error status in our function. i.e RETURN ERROR in a Sub-Procdure will cause the calling Procedures transaction block's UNDO...
I’ve just finished reading this article on SANs application burnout (http://www.theregister.co.uk/content/63/34982.html) and was wondering if anybody has experience of seeing one of these in action. And what type of performance it gives over RAID discussed above.
Thanks for the info... But now for the really stupid question! Why not do the same kind of logic for a 'FIND' statement instead of writting the following:
For each table where
a=1 and
b=2 and
c=3
no-lock:
leave.
end.
if avail table then do:
....
Is there an advantage to the way the Find...
I was wonder if anybody knows anything about the possibility that a ‘FOR EACH’ is faster then a ‘FIND’ in some circumstances. Is this true? Of just for older version of Progress? Or because of the way each command does its index processing?
Any information would be great.
Cheers,
JTWilson
I’ve been writing a Progress .W which has a number of User defined Functions, which I want to return / raise an error like a Procedure will do, if an error is encountered. (e.g. ‘DO ON ERROR UNDO, RETURN ERROR:’) But this doesn’t seem to work for me. I’ve attached a simple program to test the...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.