database in not updating for application version 2 - iphone

I have developed application which is related to sqlite database.
when added enhancement for the application there is change in database, so i have changed database by adding extra tables into existing db.
Now when all-ready exist application in device [which is version 1] update to new feature of the app. The database is not changed for version 2.
Can any one give me advice how to reflect the db for the version 2.
#advance Thanks

I have answered a similar question here, I think it can help you. The idea is to detect if your app is launching for the first time after the installation or not. If it is launching for the first time after the installation you might delete your old tables or update them... The link above illustrates how you can detect if it is the first time launch or not.

Check when Opening the connection to the Database that you run
CREATE TABLE IF NOT EXISTS
I have this in my database init
Thus checking each time that the tables exist and if not re-create them.
Then I can always drop and table and have it re-created
Or When updating and adding new tables it will check also and add any new tables

Related

How can I add a database in plugin Database Navigator (Intellij Idea Community)?

I already have a database in this manager dbs, but I have not found an opportunity to add another database to the deployed Postgresql DBMS. In the Intellij Idea Ultimate version, the database manager can do this. I can't find such a feature in the Database Navigator plugin.
I created a schema and thought to make a new database in it. But it didn't work out. Here, each database should have its own session and its own connection (I think so).
Can someone tell me how to do it ?
If you want to add another database, you should use the console for that. So, you will be able to write the query for creating this new one.
First click on your db. Once done you will write you query in the console located at the left. Follow the image to do this.
Hope this will be help you.

How to remove custom relationship in SugarCRM

The one-to-many relationship between two modules isn't needed but there is no option in Studio to delete it.
If such tables are removed manually from the database, upon running repair and rebuild SugarCRM detects the difference between the db state and some of its saved scripts. I am referring to a relationship table like:
securitygroups_cards_1_c
So, how can a custom relationship be removed permanently from SugarCRM so that it no longer appears in repair and rebuild?
I am using SugarCRM version 6.5.20
Figured it out. Following files need to be deleted to get rid of a custom relationship completely (please note that the process is irreversible so make sure you are deleting the correct files):
custom\metadata\[RELATIONSHIP_NAME]MetaData.php
custom\Extension\application\Ext\TableDictionary\[RELATIONSHIP_NAME].php
custom\Extension\modules\[MODULE_NAME]\ext\vardef\[FIELD_NAME].php
custom\Extension\modules\[MODULE_NAME]\ext\vardef\[FIELD_NAME].php
Run repair and rebuild and you are done.

Entity Framework Core Migrations in a desktop or mobile application

I don't want to sound like a jerk here, but it feels like the desktop and mobile applications have been forgotten when migrations were documented.
Given:
It is unacceptable to ask an end user to run any commands to create or migrate a database.
Its not an Asp.Net Core web application so I don't have a startup.cs scaffolded.
When the software is updated on an user's device it must update its own database without user intervention the next time it runs.
This is a code first project.
I'm pretty sure its just a matter of getting the IOC container that the entity framework core code will use and putting the right things into it, but I'll be damned if I can figure out how. Despite my best google-jitsu and bing-fu, I've only been able to find docs or examples that show running using startup.cs in web projects or using the Entity Framework core CLI tools.
public void SomeDesktopAppStartupMethod()
{
var context = new DesktopAppContext();
// ??? - register some migration locator with the IOC container? ¯\(°_o)/¯
context.Database.Migrate();
// Profit!
}
Right cause there really isn't much to the migrations of your database within in a mobile. Since more than likely you are using SQLite (guessing) mobile/uwp apps don't get some of the same treatment that Web gets this is a function of MS not pushing mobile at present if you hadn't noticed. Unfortunate for most of us early adopters but early bird doesn't always get the worm.
More than likely those doing Desktop are going to be using EF not EFC and not usually target SQLite but SqlExpress or SqlLocalDb
Most of my changes for my apps are surface level changes to the database but due to limitations of the migration system you would have to write your own SQL into the UP/Down of a migration to drop columns in SQLite and the reverse to undo your changes. The is a SQLite only limitation at present, for EFC provider.
As for location in the application where I process any migrations since I am using template10 (which is in a refactoring at present) is done where the UIElement CreateRootElement(IActivatedEventArgs e) is being created. Another location to consider would be OnStartUp for the app. It would vary based the development you are doing of course XPlat might make sense where all flavors could take advantage.
Some apps when syncing data I don't bother with migrations and wipe and recreate cause its just easier from that standpoint since all data is server based on Azure.
That being said there are major changes coming from 2.0 with respect to SQLite and EFC, if read correctly there will be a heck of a lot more control over how things are "migrated" or modified from Version X.X of your app.
We're using EFCore and SQLite for our Desktop app! This is what we did for the InitialCreate migration, I can't speak to subsequent migrations, but they should be similar (solution left as exercise to the reader):
1.For the project that contains the DBContext implementation, change the csproj ItemGroup section to include
2.Right click on the project and select Open folder in File Explorer
3.Enter cmd in the command window
4.In the command window enter: dotnet ef migrations add "xxx"
where "xxx" is the name of your migration e.g. InitialCreate, or AddNewTable
5.This resulted in some error messages for me, but in the end it created a
migrations folder with 3 new classes. Date_xxx.cs Date_xxx.Designer.cs and a YourDBContextClassModelSnapshot.cs. Add the folder and classes to your project/source.
6.Ensure your DBContext implementation has an empty ctor.
7.Replace your call to context.DataBase.EnsureCreated() with
context.DataBase.Migrate()
8.Rebuild, sacrifice a few chickens, cross your fingers and hopefully the Migrate() now creates a db with version/migration info. You can edit the .DB file which is mostly binary but will have some text like the following, which does not exist when created via .EnsureCreate()
"MigrationId" TEXT NOT NULL CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY,
"ProductVersion" TEXT NOT NULL
Notes: the first time I ran the dotnet command it failed because the EFCore designer/tools weren't loaded. I did some project rebuilds and it seemed to work after that. Also i had a lot of problems with the app during runtime getting "EFCore assembly failing to load" crashes due to different projects referencing different versions. Took many clean/rebuilds to get this working again once the .csprojs were tweaked to ref the same version. Also, out of curiosity i tried The "ef migrations remove" command, but it failed to execute (unable to load Sqlite3), fortunately we don't need to use that cmd yet.

Core Data No Longer Updating Sqlite Schema

I am using core data for my app and I never had any problems adding or removing columns until recently. But now even if I make changes to my xcdatamodel and generate new and updated entity h/m files, sqlite doesn't seem to be picking up the changes. I actually went over to the documents folder and inspected the create statement for the relevant tables in sqlite3 and I was able to confirm that the columns I added were missing.
I removed and redeployed the app several times to no avail. Is it possible to do something to the app to make it disregard any schema changes being made through xcdatamodel? I guess another thing I should mention is I recently started putting my entire projects folder in CVS so I wonder if something got messed up in the checkin and check out process.
Sorry. I feel like an idiot. A combination of "Reset Content and Settings" on the Simulator and a "Clean All Targets" in xcode seems to have fixed it.

Changing resource file in new version of an app

I'm working on an update for an already existing iphone app. The existing version contains a .sql database file which is used in the app.
I would like to use a new version of this file in the update of the app. On the first startup of the existing app the .sql file is placed in the caches directory of the users iphone. From what I can understand from Apple's documentation the files in the caches directory might get copied from the old app to the new versions caches directory when the user updates the app.
Does this mean that for being sure my new file is used in the updated version I should use a different name of the file?
And what happens with the old file? Do I have to manually delete it from inside the app? Which means I have to check if it's there at every startup of the app?
Thanks
Michael
Yes, you could use a different name, or you could use the same name, and do an "upgrade" (delete and replace) on the first time the user uses a new version.
This does imply checking at every app start, but that's not a bad idea anyways. Having some code that checks versioning at app start lets you put any data upgrade stuff in one place.
One technique is to use NSUserDefaults to keep around two pieces of information: the originally installed version of the app, and the most recently run version of the app. You check these at startup. If they're not there, write both of them. If the most-recent version is lower than the running app version, run your upgrades and bump the version. You could use the first flag to know conditionally in other places whether to expect certain data to be sitting around or not. Having versioning stored explicitly lets you know which version you're upgrading from, too, which might not be obvious if the user hasn't downloaded say 5 intervening updates.