Search results

Ideally you will never need to run dbrpr. Less ideally it could save your butt.

I don't consider anything that uses .NET to be a solution ;)

I don't even raise an eyebrow at 16GB extents. I do frown severely when I see that someone is limiting themself to 2GB extents. You probably don't really want to get into 100GB+ extents though. There are some utilities (like dbrpr) that can be used on individual extents (if needed) and having...

I would think that you would want to implement some sort of "port range" scheme similar to Progress' -minport -maxport approach and choose something else in the range when a collision happens. If you manage it with a db table you could avoid the whole "trial and error" aspect of things.

for each item NO-LOCK TABLE-SCAN where length( item.description ) > 80: display recid( item ). /* or whatever other information will help you know which item record exceeds the length */ end. You do not want to be locking records when you do this. And, since your plan is to read the entire...

Unfortunately I do now have a street number :(

Bad requirements lead to bad data. Anyhow, if I were saddled with such foolishness and couldn't get the business analyst to provide clear direction and was none the less required to do "something" to resolve the unhappiness I would probably use an easily recognizable string like NOFIRSTNAME, or...

If you lose the source database server in a fire, earthquake, flood, plague of locusts, or armed robbery then your data loss on the target is determined by what has been received on the target server (and the target server is, presumably, in a distinct physical location, not sitting right next...

“Mandatory” fields pretty much always lead to bad data because users will lie in order to move on and get their work done.

Just guessing but with 243+ extents I am suspicious that extent changes only occur with nightly backups and that new extents are being added periodically. But perhaps I am overly cynical this morning.

Extents don’t “arrive” and nothing that you are showing demonstrates anything happening in terms of extents. One would hope that “blocks received” is the same as “blocks processed”. That is the expected state of affairs. It says nothing about whether or not you are in sync. All it says is that...

It looks like I should have tested that. For now I will stick with reading from the target and then applying changes to keep changes correctly sequenced.

It is certainly possible that your ODBC connection used uncommitted reads. That would be a potential issue regardless of if ODBC connected to the OE source or the OE target.

As I said: "Your DSRUTIL output shows that both source and target are in "normal processing" and that you have zero seconds latency. So DR is as in sync with production as it can be." To verify that you are in sync: 1) run "dsrutil dbname -C status -verbose" on *both* source and target. (It is...

I have not tested this but... I am told that when a change occurs with policies MEDIUM or MAXIMUM, CDC records the values for all of the fields in the record that have a field policy. Whether they changed or not. So if you are tracking all fields you should have all of the elements of the full...

I use the MAXIMUM policy, which means that I have unique key fields that identify the record and don't have to rely on the RECID. So first I fetch the current copy of the record from the TARGET database. Then I apply the updates to that record and write it back to the target. That way updates...

You have the RECID of the changed record so you could fetch the source record using that information (this is what Pro2 does) but you should be aware that if multiple changes have occurred you could be getting later changes along with the ones that are associated with whichever tracking record...

I'm not sure what your question or issue is. Your DSRUTIL output shows that both source and target are in "normal processing" and that you have zero seconds latency. So DR is as in sync with production as it can be. That's your "headline question". You then ask about a delay copying AI files...

DBTOOL is tgiving you information about the table and its fields in aggregate, it isn't giving you a list of RECIDs to individually review. The report is saying that you have fields that are longer than what SQL would expect in table "mahead". Those are only "errors" insofar as SQL is kind of...

Aside from the other points, which are all excellent, you are not comparing "apples to apples". Your two examples are not equivalent, the first FOR EACH is not using a FIELD() list so comparing it to the OPEN QUERY that does do so is not an equivalent comparison. Your sample code also lacks...