Using the db_sqlite.getRow for a select which returns zero rows will return happily a TRow object with n empty string, as many as specified columns in the query. The implementation of getRow ignores the result value of SQLITE_DONE and returns. Shouldn't it raise an exception instead? After all, for a proc which returns a row, not returning a row seems wrong, and returning a row of empty strings potentially confusing: if you are querying for a string, you can't differentiate the empty result from an row with the empty string.
The implementation of dbError it looks up the error message for the database. I don't think that is of use, since the query didn't fail at all, so the exception should be raised manually and not through dbError.
At the moment I'm using GetAllRows and checking len on the result.
It should definitely not raise an exception as it's no error for a query to return nothing.
getRow could return @[] or nil should there be no row but I don't like that either: Then it would differentiate between 0 and 1 rows properly and return one arbitrary row should the result contain 2 or more. The semantics are 'value or ""' for each column. If that's ambiguous for the query and you really need to differentiate between 0 or 1 rows you can change the query to contain "select id, ..." or use GetAllRows.
However, the documentation should really be improved to state that. Also there should be added an additional overload getRow*(res: var TRow, db: TDbConn, query: TSqlQuery, args: varargs[string, `$`]): int that returns the number of rows in the resultset and can as an optimization reuse res's memory.