Identifying customized objects without the version list

xbo

Hi,
Is there a way (an easy way ?) to determine if an object has been modified from the standard ? WITHOUT using the version list

Savatage

Shift-f12 isn't easy enough?

Marije_Brummel

Objects provided my Microsoft have

Modified fag set to false
Time set to 12:00:00

Sometimes I use the timefield to see if there are differences.

Savatage

I guess you can create a report to print the names of the modified objects.

What's the purpose of this?

kriki

Mark Brummel wrote:

Objects provided my Microsoft have

Modified fag set to false
Time set to 12:00:00

Sometimes I use the timefield to see if there are differences.

But not even this is 100% sure. If someone set the time to 12:00:00, you won't find it.
In brief:to be 100%, you need to export the objects as text, and confront it with a Cronus.

DenSter

Of course you'd have to have a baseline to compare the object with. Like Alain said, the very best way is to do a full text compare of the object. Probably the best way to tell for sure if there is a difference without comparing code is comparing the BLOB size, and even that is not 100% guaranteed.

kriki

DenSter wrote:

Of course you'd have to have a baseline to compare the object with. Like Alain said, the very best way is to do a full text compare of the object. Probably the best way to tell for sure if there is a difference without comparing code is comparing the BLOB size, and even that is not 100% guaranteed.

The BLOB size is something I DON'T look at, because just be recompiling the BLOB size can change.

xbo

Savatage wrote:

I guess you can create a report to print the names of the modified objects.

What's the purpose of this?

As I said, I can't used the version list (has not been updated the it should for 4 years now). So using the "modified" field won't give me all the modified objects.

Marije_Brummel

If you want to be 100% sure, you need to use the Development toolkit to compare your database to the orriginal version you started with 4 years ago.

But that is not something done in a couple of minutes.

andrejsm

You can filter on the modification date, if it is after the date of version release, then object was modified.

DenSter

kriki wrote:

The BLOB size is something I DON'T look at, because just be recompiling the BLOB size can change.

The BLOB size is the ONLY field that you can't manually change in the object designer, so that is simply the best field to use whether there is a difference. For sure it could be unmodified, but at least you will have checked. Using the time/date/version list/modified flag will not give you that certainty.

kriki

DenSter wrote:

kriki wrote:

The BLOB size is something I DON'T look at, because just be recompiling the BLOB size can change.

The BLOB size is the ONLY field that you can't manually change in the object designer, so that is simply the best field to use whether there is a difference. For sure it could be unmodified, but at least you will have checked. Using the time/date/version list/modified flag will not give you that certainty.

True, you can't change it manually, but it can change by just re-compiling it (don't know why this happens). And this gives you a false "has been modified"-indication.

DenSter

My point is that I would rather check a "modified" object that is not actually modified, than miss an object because someone unchecked the modified flag, or changed the date, or changed the time. I prefer to have too many objects to compare over not enough.

Miklos_Hollender

I think these things are always relative. For a small client, who does not want to pay much for this code review, where the changes are not crucial to keeping the business go, where I have good relationship and so on, I'd just look at the time, 12:00:00, because there is a very small chance that somebody changed that or saved an object exactly that time.

Of course if we are talking about the whole management reporting system of IBM which makes the company running then NO precaution is considered too much.

Folks, please keep this thing in mind. Making Navision a bit more convenient for 40-days customer and building a sophisticated, mission-critical system for 800-days customer should be done in _completely_ different ways. Don't just blindly paste our previous experience here because the situation might be quite different.