Gray

Huh. The code definitively appends the limit _before_ the offset: https://github.com/j256/ormlite-core/blob/master/src/main/java/com/j256/ormlite/stmt/QueryBuilder.java#L551 Seems like it has been this way for a long time too – at least 4 years. Hey @wojciechsura...

Wait. I see a possible problem. The `SqliteDatabaseType` in JDBC has the limit being `LIMIT offset-number, limit-number`. I wonder if this code should be in the `BaseSqliteDatabaseType`. https://github.com/j256/ormlite-jdbc/blob/master/src/main/java/com/j256/ormlite/jdbc/db/SqliteDatabaseType.java#L35 I can't...

Really? I can't reproduce this. Are you calling `dao.create(...)` or `dao.createIfNotExists(...)`? All of the fields of an object being created are passed in as SQL arguments and should be resistant...

If this is happening with create, can you [come up with a MRE](https://stackoverflow.com/help/minimal-reproducible-example)? Thanks!

Sorry to not respond to this @yunfengsa . Did you resolve the issue.

So it is static or something? Is there no way to detect the application is starting and specifically clear it or re-create it?

I don't think you should retain the database connection. I don't think that's proper. Can you find some Android docs which say otherwise?

I think your application must be compliant. I'm not sure I agree that it's ORMLite responsibility to protect against it. This is the first time that I've heard of this...

Any chance the 2nd lookup is in another savePoint started before the delete was called? I assume no one else is creating one of these? Once the delete is called,...

Can someone generate a unit test for me to show how the code fails?