| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2111.1 | using a MIR | TOOK::CALLANDER | MCC = My Constant Companion | Wed Jan 15 1992 10:39 | 39 |
|
What needs to be understood is how the write is set up. If you do the
write using the instance key (MCC_T_UID) of the instance that already
exists, then the write attribute will overwrite the entry that already
exists. What might be happening is that in the first MCC run you
continually use the same key, in the second you might create a new one.
That's a bit confusing, so let's review it from a design stand point.
1) I assume that you have an instance repository to go along with your
attribute repository. The attribute lookup is based upon retrieving the
key for the instance it relates to from the instance MIR.
2) Before writing a new value into the instance MIR you should check if
the entry already exists; then it is up to your code to determine if it
should continue or return an exception.
3) The storage of data in the attribute MIR is free format. I tend to
store my data using ILV constructs. Since my data is not attribute data
(using the MSL definition of attribute), I use the partition code of 1
for storing all data on each entity, and then within the partition I
create an ILV construct (put_cons_begin) for each "entry" I have.
4) Note that the attribute MIR is very much case and data type
sensitive for all lookups. This means that it is up to your module to
determine how keys are to be stored. I translate all entity instances
into their DNS identifiers, and then uppercase them so that all global
instances in my MIR can be looked-up using the DNS fullname in all
uppercase.
----------------------
If this has gotten off track sorry. Try reviewing your design and see
if you can find what is causing the behavior you are seeing. There are
many potential reasons for it. If you have more questions please ask.
(Matt any other input?)
jill
|
| 2111.2 | I agree with Jill, look in the Instance Repository | TOOK::GUERTIN | Don't fight fire with flames | Wed Jan 15 1992 11:15 | 13 |
| RE:.1
Jill, super job in describing what's going on. I think on item 4,
you mean instance MIR, right?
RE:.0
Sylviane,
Jill is right, check your *instance* repository. The attribute
repository generally only writes new records when the instance key
changes.
-Matt.
|
| 2111.3 | I've fixed the problem... | BALZAC::MARKOWSKI | | Wed Jan 15 1992 12:37 | 14 |
|
Thank's to both of you for answers but you can forget this stupid
problem.
I thought that the MCC_MIR_CREATE_INSTANCE function worked like the
MCC_MIR_CREATE_REPOSITORY function that is : if the entity instance
already exists, even so it returns the instance key.
Absolutly not.
It is necessary to call the MCC_MIR_READ_INSTANCE_KEY function to obtain
the instance key in case the entity instance already exists.
sylviane.
|
| 2111.4 | Looks like a QAR on the SRM is needed | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Fri Jan 17 1992 13:22 | 16 |
| Looks like a QAR on the SRM is needed -- oh but I have already QAR'd this!
MCC_INTERNAL # 689
Either the SRM documentation should state that you should read the instance
key first and if you get NOENTITY then create it.
Or -- the create instance key should do it for you; if the instance already
exists give you the valid Id and the error ALRDYEXISTS. Then you can make
up your own mind...accept the error and reject the command, or accept the
UID and continue.
I like putting the code inside the MIR routines ... so you don't have to
put in your, and his, and hers, etc...
/keith
|