Table name not unique error

[Bill Farrell]

I've been round and round with this one.  When I compile a class for an MV file I'm getting "ERROR #5523: Table name is invalid: Table Weather.Observations is not unique. >ERROR #5030: An error occurred while compiling class Weather.Observations."  Out of a bit of desperation, I tried the following to get rid of any reference to OBSERVATIONS.

 

D ##class(%Dictionary.ClassDefinition).%DeleteId("Weather.OBSERVATIONS")

d ##class(%ExtentMgr.Util).DeleteExtent("Weather.OBSERVATIONS")

D ##class(%ExtentMgr.Util).DeleteExtentDefinition("Weather.OBSERVATIONS")

d ##class(%Dictionary.CompiledClass).%DeleteId("Weather.OBSERVATIONS")

MV

ED VOC OBSERVATIONS (and then remove the old class reference in Attribute 5)

 

Can you never ever change the name of a class or a file once you've ever had a class for it?  I thought one of my problems I'd run up against previously to be due to the fact that neither PROTOCLASS nor MVBProtoclass (PROTOCLASS's stepchild I created) handle files with multiple data levels gracefully at all.  I did modify MVBProtoclass to remove the comma and camel-case the name (like instead of "HOURLYEXTREMES,HIGH" make the class name "HourlyextremesHigh".  Same error.  Now I'm trying to replace a class name on the OBSERVATIONS MV file and getting the same answer.  It seems that I'm not getting rid of something-somewhere that needs to be gone.

 

Now it doesn't matter how I name the class (Observations or OBSERVATIONS) any class compile winds up with the same message.

 

Okay: (1) How do I *not* get into this "renaming a class" jam in the future and (2) fix the problem without reinstalling Cache and importing my data files into fresh namespaces (which seems to be the only fix).  That's awfully tedious.

 

PROTOCLASS does not completely delete old class references.  I added (and removed) the commands above to MVBProtoclass.  No soap, you cannot rename a class once it has ever been associated with a given file in a given way.  I'm guessing there's something about Storage not being updated when a class is removed (am I anywhere close on this?)

 

Any guidance will be welcome.

 

Bill

 

 

[Ed Clark]

try a sql query like:
select name from %Dictionary.ClassDefinition where lcase(name) [ 'weather'
select name from %Dictionary.ClassDefinition where lcase(name) [ 'observations'
to see if there is a casing issue (though I would expect the error message to say so if it were a casing issue)
Also take a look at %ExtentMgr.Util.GlobalUses() and check to see if the global that the file would use for storage is in use.
Make sure the the MVFILENAME class parameter doesn't conflict with an existing file.

> --
> You received this message because you are subscribed to the Google Groups "InterSystems: MV Community" group.
> To post to this group, send email to Cac...@googlegroups.com
> To unsubscribe from this group, send email to CacheMV-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/CacheMV?hl=en

[Ed Clark]

also, look at the class storage deffinition and see if there is anything odd about the globals it want to use:
<DataLocation>^mvfilename</DataLocation>

On Mar 22, 2012, at 12:00 PM, Bill Farrell wrote:

[Bill Farrell]

Thanks, Ed. You're definitely the "go-to" man for the Deep Thought answers.
That export/import worked out really well. I'll whup up a wrapper when I
get home. I'll add the SQL queries to my class after I fiddle with them at
the command line to see how I'd like to code it.

I deleted the MV file I was working on, used the suggested export/import
calls and ran MVBProtoclass again. Now this may be a difference between
2011 and 2012.1. I'm now getting another error: "ERROR #5475: Error
compiling routine: Weather.Observations:%SQLGetOldALL. Errors:ERROR: source
lines(18_ : MPP5377 : You are attempting to call instance method
'EntryDateGet' from a class method" . .. and so on for each virtual field.

The property is defined as:
Property EntryDate As %MV.Date(MVAUTO = "P", MVITYPE = "IConv( @ID[5,2] :
'/' : @ID[7,2] : '/' : @ID[1,4], ""D"" )", MVNAME = "ENTRY_DATE",
MVPROJECTED = 1, MVTODISPLAY = "D4/", MVTYPE = "I") [ Calculated,
SqlComputeCode = { d ..EntryDateGet()}, SqlComputed ];

and the Get accessor is:

Method EntryDateGet() As %MV.Date [ Language = mvbasic ]
{
theRecord = @ME->Record
Result = IConv( @ME->Key[5,2] : '/' : @ME->Key[7,2] : '/' :
@ME->Key[1,4], "D" )
return Result
}


exactly as I've done since 2011. (IIRC it also worked fine on 2012.1 FT1).
I'm wondering if there is a change in the way SQL gets built around the
file/global/class. I did try recoding the Get() accessor builder to mark
the methods as ClassMethods, but I got another error "ERROR #5477: Keyword
signature error in Weather.Observations:Method:EntryDateGet, keyword
ClassMethod must be '0'".

Darned if I do, darned if I don't. Odd.

B

[Ed Clark]

Did that class actually work with SQL on the previous version? As far as I know (and I could be wrong) the SqlComputeCode has to set the property, and doesn't run with a normal class context, so instance methods can't be used. It needs to be something like:
SqlComputeCode = {Set {EntryDate}=##class({%%CLASSNAME}).calcEntryDate({%%ID},{%RECORD})}
A propertyGet method needs be be an object method, but methods called in sqlcomputecode need to be class methods. Maybe the class compiler has been enhanced to give a compile-time error.

[Bill Farrell]

On that last, I overrode SQLComputed and Calculated since I add Get/Set
accessors automatically for each property in MVBProtoclass. It works great
now. I'll work with the SQL query to make sure there are no "ghosts" or
open classes laying around this evening.

Thanks Ed,
B

[Bill Farrell]

The combination of all three is full of win. I've tested it in a
ditty and will be adding that to my main MVBProtoclass.

There is a -DEL switch available on my MVBProtoclass command. I
suspect that I wasn't finding every possible permutation of
"OBSERVATIONS" before and that's how the global metadata got hosed.
Once I'm happy with single level files I'll try multiple data level
files. It will be a lot easier to see where things go wrong with all
three queries in place.

> > For more options, visit this group athttp://groups.google.com/group/CacheMV?hl=en- Hide quoted text -
>
> - Show quoted text -