Thank you guys very much for answering, Igor, i belive you are right. I think it is a typed dataset .NET bug. There exists an option to use optimistic concurency. If it's on then it uses rows affected to check if row was modified or not. The stupidity of it is even if it is turned off ( checkbox unchecked ), it still throws the exception. I am hoping that someone else working with System.Data.Sqlite and Typed dataSets encountered the same problem, and perhaps knows the solution. Well, at least i have reduced the problem to typed DS, and eliminated SQLite connector.
Alem On Fri, Dec 21, 2012 at 1:48 AM, Igor Tandetnik <i...@tandetnik.org> wrote: > On 12/20/2012 7:21 PM, BareFeetWare wrote: > >> The changes are in fact made, but those avenues for checking don't work. >> I'm tempted to label this as a bug in SQLite, since I see no reason for the >> limitation. >> > > If the trigger changes 20 records across 5 tables, which results in 63 > rows in the view visibly affected, which value should sqlite3_changes > return? > -- > Igor Tandetnik > > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
