Problems when class are compiled.

[Andre Luis - Shift]

Hi all,

When I compiled class and these classes have MVFILENAME, sometimes an
error occur.
See bellow:

ERRO #5002: Erro Caché: <NAMESPACE>zCreateProjection+78^%Projection.MV.
1

I am worried about it, because the unique way that we found to solve
the problem is to delete the MV file name and create it again. But, we
have a case which the client has data and we can’t delete the mvfile
name.
What should I do to solve it?

Thanks in advanced.

[dawn]

Hi Andre -- did you get an answer to this? Sometimes we have to clear
storage, although I do not recall a compile error like this one. --
dawn

[André]

Thanks dawn,

I would like to know if I clear my storage I would have the risk to loss the data?

2009/10/9 dawn <dawnwo...@gmail.com>

[Doug Golder]

If you delete the storage in the class and recompile the error will go away and you will not lose your data.  I have an open case with cache on this wrc # 712191

[André]

Ok. Thank you.

I will try it. 

 

2009/10/12 Doug Golder <doug....@mstarmetro.net>

[Dawn Wolthuis]

No, you will not lose your data, but I'll confess to not being
entirely clear on this point. We have never lost data when clearing
storage to my knowledge.

For some changes to our persistent class metadata, when we need to
move the source code around to different accounts, we also need to
clear the storage (a terrible-sounding thing to do to a file, very
concerning indeed, so I understand your question) and then recompile
the source to get the class and the data aligned and working.

I wish that the source could stay as source and everything could be
generated from the specification we give so that when a class is
compiled, we didn't have to guess whether we just adversely affected
everything because of this "storage thing". The only thing I know
about related to storage is that we put MVATTRIBUTE = 3, for example,
as an attribute of a Property instead of letting the compiler assign
the location based on the order of the Properties so that this storage
beast does not retain information from the last time and potentially
put different LOCs on the same attribute in different accounts.

Because we have accounts where the source code is locked down, we
cannot simply go in and clear the storage as part of the process of
updating a persistent class, so we do some messin' around, sometimes,
sadly, after we figure out that things stopped working in some
account. I would be happy to see this storage beast always be
refreshed from a compile as an option so that we do not get this
residue in the system. I suspect that would have saved us quite a few
hours of debugging time from several people to date.

cheers! --dawn

--
Dawn M. Wolthuis

Take and give some delight today

[Jason Warner]

One thing to be aware of is that if your storage positions change after wiping out the storage section, you could wind up with data that looks corrupt. I had a case where the original storage definition had the VIN in position 3. However, after recompiling, the compiler moved its storage definition to position 5. This caused a bit of a headache until I realized why. You may want to specify your MVPOSITION before deleting the storage definition.

Jason

On 10/12/2009 12:17 PM, André wrote:

[Dawn Wolthuis]

Yes, from the experiments I have done (which were done before several
enhancements in this area, I'm guessing), I would not have any
%Persistent class without the MVATTRIBUTE attribute of the properties
(is MVPOSITION the same thing?) If you don't tell it the LOC of the
field, it will try to figure it out either from the order in your
source code or from this funky "storage" thing. Don't let it try to
guess as it will get it wrong sometimes. Unfortunately, sometimes this
storage guy messes with you anyway, and I believe the decision on
whether to have the storage mess you up is make randomly ;-)

--dawn

[Jason Warner]

No, I put the wrong attribute. MVATTRIBUTE is the one that you need to
pay attention to. That's what I get for not verifying my information
before sending it :)

Jason

[André]

In my case, I always define MVATTRIBUTE.

I did some tests and I didn't lose the data, and the position continued like it was, even when I add a new attribute.

Thanks 

 

 

2009/10/13 Jason Warner <jas...@brashers.com>

[edclark]

I sent this response a few days ago, but it didn't get into the group,
I think because I switched mail servers and had a different "from"
name in my email:

No you don't risk losing data. The "storage" we are talking about is
the classes storage deffinition--the details of where and how the data
is stored, but not the actual stored data.

The storage definition is hidden by default in studio, but you should
probably take a look at it and get familiar with what it does. In a
class created by protoclass for a simple name/address file named MINE,
the storage looks like:

<Storage name="Default">
<Data name="MINEDefaultData">
<Value name="1">
<Value>NAME</Value>
</Value>
<Value name="2">
<Value>ADDR</Value>
</Value>
<Value name="3">
<Value>CITY</Value>
</Value>
<Value name="4">
<Value>ST</Value>
</Value>
<Value name="5">
<Value>ZIP</Value>
</Value>
</Data>
<DataLocation>^|"THHOME"|MINE</DataLocation>
<DefaultData>MINEDefaultData</DefaultData>
<ExtentSize>100000</ExtentSize>
<IdLocation>^|"THHOME"|C.MINE</IdLocation>
<IndexLocation>^|"THHOME"|I.MINE</IndexLocation>
<StreamLocation>^MVFILE.MINES</StreamLocation>
<Type>%Library.CacheStorage</Type>
</Storage>

You've got blocks in there that define the storage "slot" for each
property, like
<Value name="1">
<Value>NAME</Value>
</Value>
which means that property NAME is going to be stored in slot #1, which
for a multivalue file translates to attribute #1. For the most part
this "just works" but some problems can arise. For example, if you
rename the NAME property to be CustomerName, the class compiler will
not replace the storage entry for NAME. It will leave that alone, and
create a new slot for CustomerName--slot 6 in this case. The compiler
does that for a reason. It can't tell that CustomerName replaces NAME.
All it knows is that NAME is gone and CustomerName is new. So it holds
the slot for NAME--assuming that there may be data in the slot, or
that some legacy non-object application may be using that slot.
You can get around this default compiler behaviour by either deleting
the storage definition before recompiling, or purposely editing the
storage definition yourself, putting CustomerName in in place of Name.

You also have block in there that define what globals are going to
hold the data:
<DataLocation>^|"THHOME"|MINE</DataLocation>
In this case, the data is in the global ^MINE in namespace THHOME.
Under some circumstances, the namespace name is hard-coded into the
class, so in order to copy the class to a different namespace and use
it there, the storage needs to be ammended. Again, you can update it
manually, or just delete it and have it build a new default.

> > >> 2009/10/9 dawn<dawnwolth...@gmail.com>