5.修改数据
修改数据首先也是取出对应的实体对象，然后通过修改对象的属性，最后保存上下文。
-(void)modifyUserWithName:(NSString *)name screenName:(NSString *)screenName profileImageUrl:(NSString *)profileImageUrl mbtype:(NSString *)mbtype city:(NSString *)city{
User *us=[self getUserByName:name];
us.screenName=screenName;
us.profileImageUrl=profileImageUrl;
us.mbtype=mbtype;
us.city=city;
NSError *error;
if (![self.context save:&error]) {
NSLog(@"修改过程中发生错误,错误信息：%@",error.localizedDescription);
}
}
调试
虽然Core Data（如果使用SQLite数据库）操作最终转换为SQL操作，但是调试起来却不像操作SQL那么方便。特别是对于初学者而言经常出现查询报错的问题，如果能看到最终生成的SQL语句自然对于调试很有帮助。事实上在Xcode中是支持Core Data调试的，具体操作：Product-Scheme-Edit Scheme-Run-Arguments中依次添加两个参数（注意参数顺序不能错）：-com.apple.CoreData.SQLDebug、1。然后在运行程序过程中如果操作了数据库就会将SQL语句打印在输出面板。
注意：如果模型发生了变化，此时可以重新生成实体类文件，但是所生成的数据库并不会自动更新，这时需要考虑重新生成数据库并迁移原有的数据。
FMDB
基本使用
相比于SQLite3来说Core Data存在着诸多优势，它面向对象，开发人员不必过多的关心更多数据库操作知识，同时它基于ObjC操作，书写更加优雅等。但是它本身也存在着一定的限制，例如如果考虑到跨平台，则只能选择SQLite，因为无论是iOS还是Android都可以使用同一个数据库，降低了开发成本和维护成本。其次是当前多数ORM框架都存在的性能问题，因为ORM最终转化为SQL操作，其中牵扯到模型数据转化，其性能自然比不上直接使用SQL操作数据库。那么有没有更好的选择呢？答案就是对SQLite进行封装。
其实通过前面对于SQLite的分析，大家应该已经看到KCDbManager就是对于SQLite封装的结果，开发人员面对的只有SQL和ObjC方法，不用过多libsqlite3的C语言API。但它毕竟只是一个简单的封装，还有更多的细节没有考虑，例如如何处理并发安全性，如何更好的处理事务等。因此，这里推荐使用第三方框架FMDB，整个框架非常轻量级但又不失灵活性，也是很多企业开发的首选。
1.FMDB既然是对于libsqlite3框架的封装，自然使用起来也是类似的，使用前也要打开一个数据库，这个数据库文件存在则直接打开否则会创建并打开。这里FMDB引入了一个FMDatabase对象来表示数据库，打开数据库和后面的数据库操作全部依赖此对象。下面是打开数据库获得FMDatabase对象的代码：
