Really, you have posted insufficient information. We are commenting on the code that you have posted, but then you say you do more checks further down the line, so our comments become useless. We don't know your form nor your database, so we are basically answering blind with generic information, so to speak.
I would change your return value too, returning 0 (FALSE) for OK seems a little strange. Imagine the code calling your validation - if (!ValidateForm()) { // Form is OK } looks odd and is not self-documenting. Personally, I would probably create an enum and return something like VALIDATE_SUCCESS or something like that.
Secondly, I would change the sql to a stored procedure, something like:
CREATE PROCEDURE isInvoiceEntriesPresent
AS
SELECT COUNT(1) FROM tempinvoiceentries;
CREATE PROCEDURE isInvoiceEntriesPresent
AS
SELECT COUNT(1) FROM tempinvoiceentries;
To copy to clipboard, switch view to plain text mode
and then your query becomes more self-explanatory:
query.exec("{call isInvoiceEntriesPresent}");
query.exec("{call isInvoiceEntriesPresent}");
To copy to clipboard, switch view to plain text mode
This also means you can change your method without having to recompile your code. Assume you are on a customers site with a problem, altering SQL is easier than having to do a full recompile and redeployment.
Unless your interested in the content of the data fields (ie, non-null), use COUNT(1) as above instead of COUNT(*). The former will give you more performance as it doesn't have to retrieve all the database data. Another reason for stored procedures is that they are typically pre-compiled (depending on the underlying implementation), so don't need to be parsed and offer even more performance.
etc...
Bookmarks