The LwM2M spec does not specify what happens to an object instance's observations when a server deletes the object instance.
For example, if a server has installed an observation on /5/0/3, then deletes /5/0 and subsequently creates a new /5/0, should the server assume that the observation on /5/0/3 no longer exists, and should be reinstalled?
Thanks,
Bryan
Related
I have an RTD server that I created, and I want a different instance for each workbook as each workbook will use a different API key to access some data. In other words, if I open Workbook1, and it uses Key#1, when I open Workbook2, I don't want it to use the same instance.
I know this probably has something to do with COM, and I have tried changing flags to "multiple instance", and I have tried modifying the singleton pattern, but the root problem seems to be that the instance that is created of the exe is the same.
I need to change a package for ~250 SAP development objects (ABAP classes, data elements, tables, etc). I'm getting an error message TR242 (Object already exported, no package change is possible) when I'm trying to do the change via se24/se80 transactions or via RSWBO052 report.
SAP help docs say that the object must be copied under new name, the old one must be deleted and the new one must be renamed to the old name back. However, it's not a good way for 250 objects.
Is there any way to do a mass package change except call tranaction/LSMW for this case?
The problem occurred because I was trying to move the development objects to a non transportable package as #vwegert metnioned above. The target package was marked as non transportable because it was marked as a legacy one. This happened because the target package was moved from a system with basis level lower then the current system basis level. Next steps are necessary to resolve the issue:
The legacy package must be migrated via report RS_MIGRATE_PACKAGES (see note 1711900). The mark 'legacy package' will be removed, but the package will be still non transportable. However, you will be able to recreate the package after the migration.
Delete the non transportable target package and create a new as copy of the non TMS package.
Assign all necessary objects to package created at step 2 using RSWBO052 report.
This message occurs if you try to move objects from a transport-enabled package to a non-transportable package like $TMP. The rationale behind this is:
The object once was in a transportable package, so it must have been added to at least one transport request.
The transport request might have been transported to another system (directly or via ToC), so the other system might have that object.
The current system is the original system of the object, so it is responsible for notifying the other systems (via transport) when the object is to be deleted.
Moving the object to a non-transportable package is semantically equivalent to deleting it for the rest of the system landscape.
Since that process happens very infrequently, it's usually sufficient to direct the developer to copy and delete the object.
Whenever I restore an AS Database, the DB files are created in a new folder by name DBName_[1-n] wherethe number is incremented by 1 after every restore. I am currently looking for a script to copy the files[or this ASDBName_[n]] dynamically to another server.
Is there a way to find the file path of the ASDatabase through DMVs/ AMO or any other manner?
Regards,
Sasi.
The numbering is used by AS to handle transactions: Each write operation creates a new copy with a new number, while the old version can still be used for read access. If, finally, the write operation - be it a restore or a processing or a structural change - succeeds, AS switches all users to the new version, and can then delete the old version in the background. If anything goes wrong during the write operation, the new version can just be deleted by AS without affecting anybody using the previous version. This can happen on database level, and as well at sub-object level (if you e. g. process only a dimension, or add a measure to a measure group).
This also means that in order to be sure you copy the database, you have to detach it - which makes sure that it is in a consistent state, and not a half written rest stays around. Then you could copy it to a new server, and attach it there. And, as long as the database is detached, there should be only one version, so you could just take the one and only folder of name "DBName.<n>.db".
I do not think there is a documented possibility to find the exact name. At least, Microsoft does not document one at http://technet.microsoft.com/en-us/library/cc280670.aspx. They just state "Use any operating system mechanism or your standard method for moving files to move the database folder to the new location."
I have created total 50 test scripts. All these scripts use almost same objects so I have created a Shared Repository to ease the maintenance work.
But the problem is...
While executing scripts in Update Run mode, QTP adds some objects in local repository even if they are present there in Shared Repository. I have checked properties of these newly added objects and there are no change in that too.
Anybody please tell me the logic QTP uses to decided whether to add a object to local repository or not.
Also tell me a solution so that no object is added to the local repository.
There are two things at work here.
QTP opens Shared Object Repositories (SORs) in read only mode
since SORs are by definition shared, QTP wants to make sure that
when someone makes a change to a SOR he is aware that many tests may
be affected. Therefore in order to edit a SOR you have to use the
Object Repository Manger and no changes are made to a SOR
automatically (Update Run Mode or Maintenance Run Mode)
When adding an object to the object repository QTP first checks if the object already exists (by comparing properties) if it does it reuses the existing object and doesn't make a new entry.
This explains why you're getting objects in the Local Object Repository (LOR) and not the SOR, (I'm not sure if having unmodified objects added to the LOR is the correct behaviour or not).
In order to propagate the changes after the Update Run Mode you should export the LOR to a new SOR and then merge it with your existing SOR.
I also faced similar kind of problem. While execurting script qtp was not identifying an object although object was present in shared OR and it was highlighting in application. when i checked in maintenance run mode there was a change in one prperty value which i updated in shared OR. The problem was I spy on that object and qtp saved it in local OR. so next time when i run the script it was refering from local OR and script was failing. so i deleted object (which was showing as Local) from object repository window , then it displayed the same object of shared OR (which was QC path)
I'm using NSCoding to encode my objects and save them to disk as a "caching" feature not having to download data every time my app is started. Right now I'm saving this data in the Documents folder of the app which I have read is not deleted when updating the app.
So my concern is that I do some update to my class like adding an instance variable. And then uploads the app to the App Store. So when the user updates to new version the old objects that are saved in the Documents folder are encoded without that new instance variable that I had added in the new version. So that when my app will try to decode the saved objects during startup it will fail because the "old" objects from the Documents folder were not encoded with this new variable?
How would I deal with this problem? Make sure I write my classes "right" from the start? I'm sure I will eventually need to modify one of my classes and then break the old saved objects on disk.
Change either the filename or encoding key of the objects when you decide on a new version.
For example if you are now saving your objects in an collection to 'myObjectsFile', when you have a new version use the filename 'myObjectsFile2'. When your application launches check for 'myObjectsFile' if it is there load your old objects and migrate them to the new object version, then save those migrated objects to 'myObjectFile2' and delete 'myObjectFile'.
On the next launch you are all set, since you have deleted 'myObjectsFile'.
YOu can version your objects by having a version property that you would guarantee to always be there.
After loading an object from disk, don't do anything except check the version property. (You could also check for the existence of the version property first.) If your current code base does not support the version of your object, simply discard it.