I'v built the app, with a working datamodell with one entity. The managedObjectContext works fine with the arrayController, and a TableView. A pretty straightforward, and common setup.
There's almost no code yet, I'm just trying to play a bit with coredata.
The problem is, when I change the modell, for example add a new entity, it no longer compatible, end show two errors while loading the app.
here are the errors:
The managed object model version used to open the persistent store is
incompatible with the one that was used to create the persistent store.
Failed to initialize the store
I guess somehow it tries to load to last model to the array, but i'm not intrested in that. I want to use the new one, and get rid of everything else.
I search stackoverflow and google all around, so I've cleaned the build folder, cleaned the app, still not working. Those folders in Library or Library/Application for my app name does not exists.
How to solve the problem, and make the app to use the new DataModel?
You have to delete the store file (the actual sqlite store). It will be recreated in your AppDelegate when you start the app again.
If you are using the simulator, you can go into the documents folder and delete it yourself. (Complicated.)
You can set a flag in your program and delete the store if set to true. That is a good setup for testing, especially when your data set is not too large and if you do not need your entered data to persist across relaunches. (Recommended.)
You simply delete the app from the device / simulator. (Easiest.)
Related
I have a SQLite database with two columns it is bundled in the app. There is no write or save interaction in the database, it is fixed and read only. I read some documents and tutorials about the lightweight/manual migration all make it clear that you have to save the user data when migrating, that is not my case I don't need to save user data, I will deploy a new app version with a new database. I want to add two new attributes to my database and use in the app. Why I have to migrate? Why can't I just delete the old three files of SQLite database and add the new one and use the new attributes as needed. So I tried and did not work, anyone here to give me the steps to make the app to recognize the new database?
Actually the way to delete the SQL database files is the right way.
But you have to do that before the Core Data stack is going to be initialized.
Kofax Capture Version 9
I have an existing Project and Batch class that works, built previously by Kofax engineer.
What I need to do is change the script in the project to use a new DB connection. This seemed simple enough.
Using project builder I copied the existing project, altered the script and saved the project. Using Capture Administration I copied the existing batch class and then used Synchronize Kofax Transformation Project and pointed to the new project. All this seemed to work without error.
However the script being executed is the original not my altered one, any guidance would be great.
Make sure you are creating a new batch after publishing your change. The batch class class update function works in very limited scenarios, so I don't generally recommend it.
There are many ways that a database connection might be handled in script. Usually I would expect that a function at the project script level handles the connection and is called from any sub class, but you might want to check any sub classes to make sure they aren't using locally defined connection strings.
Even if you are making a connection in script (which you've now changed), you might also be using product features that use databases. Open Project Settings and check the Databases tab.
If there are relational databases listed, simply change as needed.
If you are actually using "Remote Fuzzy" databases then these might be using Kofax Search and Matching Server which connects to a relational database to build the fuzzy db. In this case you would need to use KSMS Admin to change the connection on the KSMS server.
If you are using "Local Fuzzy" databases then the info is based on the content of a text file. You might have some external process (possibly Markview) that dumps this text file from a database.
I set up my working Core Data sqlite file for versioning. The versioning setup process created 3 files:
foo.sqlite
foo.sqlite-shm
foo.sqlite-wal
Since then, I can access the Core Data store programmatically (using MagicalRecord), but I can't read any data using either the Firefox add-in (SQLite Manager) or the app SQLiteManager. I'm concerned that when I send the updated app to the App Store, the additional files are not going to go and the app is going to crash.
What do I need to do to make sure new versioning-enabled sqlite files go with the app?
Those are not version-related files, they're SQLite log files. These files get created automatically when write-ahead logging is enabled. That's not the default in iOS 6, but it's possible if you use PRAGMA journal_mode=WAL;. It might or might not be the default in iOS 7 (I have no comment at this time).
I don't know why Firefox and SQLiteManager can't open the file. I speculate that they're both using an old version of SQLite (since WAL is only available as of SQLite 3.7.0). Regardless, they have nothing to do with whether the necessary files are available in your app. You can find out what's included in the app by just looking. The .app is just a directory, really, so take a look inside and see what's there.
If you are using lightweight migration (wich is enabled by passing the
right options when you open the store), Core Data takes care of
upgrading the schema in-place.
The additional WAL and SHM files are not a result of lightweight
migration, but are instead simply produced by SQLite in the “write
ahead logging” mode that Core Data puts it into. (An
oversimplification is that new data goes into the .wal file until
enough accumulates and then it is moved to the .sqlite file.)
Yes, you definitely want to test using Ad Hoc builds for lightweight
migration; testing from Xcode is insuffient.
Mike Fikes
I have a CoreData store managed with MagicalRecord. I did a successful migratiion, but lost the data in the newly created store. This is what I have:
salonbookV1.0 is the original xcdatamodel for the initial store. I added only new attributes to an existing entity, and the mappingmodel looks like this: (a partial image).
Let me elaborate on what I did...
created the xcdatamodeld folder with both xcdatamodel's in it
marked the salonbookV1.0 as the current version and ran the app creating some entries
stopped the app, and marked salonbookV1.5 as the current version and ran the app
data which was entered previously was gone! (apparently the migration did not occur)?
The migration was accomplished; I know that because I can use the new attributes. However, the existing CD store was deleted. I have read all I can on MR, and there is only one method that deals with migration; MR does the rest without any coding from me.
So the question remains: why is the existing store being deleted?
I don't know about MR but in "normal" Core Data you have to set the NSMigratePersistentStoresAutomaticallyOption to the persistent store, otherwise it will not migrate your existing data to the new store version.
Here I have some entities in core data, for example, "Account",
and I wish that, when user enter my app for the first time, there is some thing in Account,
to make it more clear, maybe I should say I want to give some default managed-objects for an entity so that they will be there when the app is just installed.
How can I achieve this?
Thanks a lot!
I have a similar requirement for an app I'm working on. I am using a sqlite persistence store for my data, so I basically want to pre-populate that table with the data for my default entities.
To do this, I have created a separate project in my Xcode workspace that shares the same data model with my app. In this separate project I write the code I need to insert entities into the table, and to store the file in a well-known place on my Mac.
Then, I copy the sqlite file that my initializer app has created into the resources directory for my "real" app. As part of the startup for that app, I wrote a small bit of code that copies the default DB from the resources to my app's documents folder if a copy doesn't already exist there.
The end result is this: I can run my initializer app to populate the default data as I need to. I then copy the file into my real app, so when the app is first run there is a default copy of that DB ready to go.