Appending Dataset in Core Data execution of Update through iTuneStore - iphone

This one Also Resolved by myself.
Good answer would be,
New Edition App: make change the sqlite file name. check file exist, get the old edition app sqlite name value then remove, and add into that folder.
this is the best answer.
*New efficient answer
STEP 1: select .xcdatamodel file
STEP 2: Xcode -> Design -> Data Model -> Add Model Version
STEP 3: Manipulate new changes
For more detail about migrate or re-organize data model structure, visit Apple <here>
Although I didn't quiet sure how to add model version before reading Apple's document, My old way is still works.
Old resolved self answer
Example from 'Reciepe' given by apple, it don't replace the file if it is there already.
However, if your code need to update and get rid of old .SQL file then the explicit condition needed for check the old file sqlite name deleting function required for update.
Basic sequence would be,
CHECK 1: check if old file exist.
CHECK 2: if it does, remove it.
CHECK 3: then copy new one.
CHECK 4: if the old file don't exist,
CHECK 5: (if the new file don't exist),
CHECK 6: copy new file into that folder.
CHECK 7: if new file exist do nothing.
solved.
Original Posted Question
So I have completed my code work.
This is first time releasing the app through iTuneStore.
Current state of reading Core Data (.sqlite) file is already prefetched (already has information like apple's 'Reciepie' program).
Assuming I have successfully released through apple store, and decide to update my application to existing users.
Say I have sqlite contents but it contains bit more information than previous SQLite file under same structure.
Question 1. Every time update held to the existing user, does it removes previous ones and move new updated application?
Question 2. if it is not, then HOW can I append the existing sql value?

If you do not change the underlying data model, then the answers are:
1) updating from, say v1.0 to v1.1 does not remove the previous contents already stored and managed by Core Data.
2) Simply check the version of your application using the main bundle, and, if the version retrieved needs additional data to be inserted, do the insert. You can do the check and the insertion in
- (void)applicationDidFinishLaunching:(UIApplication *)application;

Related

How to do duplicate file check in DataStage?

For instance
File A Loaded then next day
File B Loaded then next day
This time Again, File A received this time sequence should be abort
Can anyone help me out with this
Thanks
There are multiple ways to solve this, but please don't do intentionally aborts as they're most likely boomerangs.
Keep track of filenames and file hashes (like MD5sum) in a table and compare the list before loading. If the file is known, handle/ignore it.
Just read the file again as if it was new or updated. Compare old data with new data using the Change Capture stage, handle data as needed, e.g. write changed and new data to target. (recommended)
I would not recommend writing a sequence that "should abort" as this is not the goal of an ETL process. If the file contains the very same content that is already known, just ignore it. If it has updated data, handle it as needed. Only abort, if there is a technical issue, e.g. the file given is wrong formatted. An abort of a job should indicate that something is wrong with the job. When you get a file twice, then it's not the job that failed.
If an error was found in the data that needs to be fixed by others, write the information about it to a table. Have a another independend process monitoring that table to tell the data producer about it (via dashboard, email,...).

In which file is the _AppInfo data stored in Beckhoff TwinCAT 3 PLC

I'm looking for the 'AppTimeStamp' information so this can be used to verify that the code is not updated/changed by service personel.
Detect code changes on Beckhoff PLC using C#
At this location I already find part of my information, but I was not able to add a comment due to the 'new user' limitations
You can find the AppTimestamp in the _AppInfo instance.
So just call _AppInfo.AppTimestamp in your program to know the time of the last application start.
Make sure you also check the number of online changes since last download with the OnlineChangeCnt counter which you will also find in the _AppInfo instance.
There are many possibilities where this value is saved. The TwinCAT saves data to the C:\TwinCAT\3.1\Boot folder, different files are explained here.
The ProjectName can be found for example from the configuration data (CurrentConfig.xml), from the end of the file (TcBootProject/ProjectInfo/ProjectName). The same file contains one date (<TcBootProject CreateTime="2019-06-10T13:14:17">), but it seems to be the build time of the boot project created.
I couldn't find the date of AppTimestamp in any files, but perhaps the TwinCAT uses the creation time of the files in those folders? Or perhaps it's hidden in the binary somewhere.
When you update the software without updating the boot project, the file Port_851_act.tizip is updated. So you can check its timestamp. When you update the boot project too, Port_851_boot.tizip and other files are also updated.
So basically, to check if the code is updated by someone, check that modified dates of the files under Boot directory. I suppose only .bootdata files should update as they contain saved persistent data. Of course, you can easily change the dates with 3rd party program. So one solution is to compare the Port_851.crc file contents since it contains the CRC check value of the code. It will always change when boot project is updated.

Determining whether mongodb save method really update a record or not

My question is clear as in the title. When a request come to my service for updating related record in mongoDb, we use "save" method.
However, I would like to understand whether the save method really updates the record or not.
In other words, I would like to know if the content going to save is the same with the existing content in mongoDb. Accordingly, even if save method is executed without any errors, is it possible to understand whether it is really updated or not?
Thanks in advance
There are several ways to checks this.
The first is after calling Save, is to call the getLastError method. Within the console this is just db.getLastError().
This will tell you if an error occurred during the last operation. More details can be found at te following address http://docs.mongodb.org/manual/core/write-operations/#write-concern.
Another way would be to call findAndModify, this will allow you to update the document and either get the updated document back.
http://docs.mongodb.org/manual/reference/command/findAndModify/
Both of these are available in all of the official drivers.
Save method always writes the record.
There is no situation in Mongo where the write would not happen because the record that is being saved is identical to the record that's already there. The write would simply happen and "overwrite" existing data with new data (which happens to be identical).
The only way you can tell is by comparing the old and new documents - and that's a lot of extra work.

Changes in sqlite file when creating new version of App

i have a sqlite file in my app. the app is with enterprise certificate .
Now , if i am going to create new version with the changes in database then :
1) i have to change my Sqlite file name ?
2) if yes , then is there any way that if any person who is using my app, who has his saved data in app , will be inserted automatically in new version of my app .
otherwise if i create new file and then the older data would be removed!!!
Thanks in advance..
1) AFAIK, when you update, the old app bundle is replaced with the new app bundle. But the user data is untouched. i.e. the copy of the sqlite DB which the app changes with use by the user, is not deleted/replaced.
2) So, you can possibly ship changes to the DB as queries:
a) New tables go in as CREATE TABLE queries.
b) Changes to table structure go in as ALTER TABLE queries.
3) Now, one problem is, you didn't think about all this when you shipped the older version. So how will you make sure the queries 2a and 2b are executed only on upgrade?
a) When you first get control in the application, before allowing user interaction, fire a dummy SELECT SINGLE * FROM <tablename> on a table you have 'changed' in new version.
b) Use sqlite3_column_count and sqlite3_column_name to find out which version of the app the DB corresponds to [old or new].
c) If it is new version (i.e. new columns already exist), do nothing, else fire the queries I mentioned earlier as 2a and 2b.
If you haven't started by using this, then it's probably moot, but Core Data handles migrations (IMHO) fairly well; enough that it's worth the hurdle of learning the API. We've had great success with it (including complex migrations, inserting new objects "between" relationships, etc).

iOS - Create Database Schema (Run code only once)

I'm using FMDB for my iPhone App database and i want to create the database and tables schema only once.
How can i run OBJC code when the user installs or updates the app?
Kinds Regards
You can set a boolean value in NSUserDefaults - NSUserDefaults is only reset when the user deletes the app, so you have some code that executes if a particular boolean value is not found in the user defaults (and then saves that value after execution to prevent it from being run again).
That will cover your plain 'run code once upon install' scenario - you can achieve the same for updates with a similar approach, but utilising the CFBundleVersion variable (which will be different for each version of your app).
First of all, you might not want to think about executing something during upgrading, because it's not possible. Like #lxt suggested, you can store a value in the preference to indicate database version, but it might not be bulletproof.
A common approach to solve this problem is to use self-built meta-data. When you first created the database, you should create an extra table named "metadata" or "properties", with two varchar columns, "name" and "value". You insert one row, ("database_ver", "1").
In your database layer (or adapter) class, you create an "open" method to handle opening. Within this method, you first run select database_ver from metadata; to check database version. If nothing is fetched, you run table creation scripts, and insert database_ver=1 row.
Later on if you upgraded your table format, provide alter table statements for each version, and run them based on database_ver. For installations after the upgrade, you can use the updated create table statements, then set "database_ver" to "2" (or above) directly, without going through alter table.
Compared to storing value in the preference, it's actually more common to store it in the database itself. Because even if the user backed up the file somewhere, or skipped a version, you can still tell the format of the database by its metadata table.
FMDB has no problem running such mechanism.