Store error vector and SQL state in DatabaseException

[fdcastel]

Store error vector in DatabaseException

Fixes #24

Summary

DatabaseException now stores the Firebird error vector (ISC error codes) and SQL state from the original status vector, making them available for programmatic error handling.

Previously, DatabaseException only stored the formatted message string (via what()), discarding the raw error codes. This made it impossible to map Firebird errors to SQLSTATE codes — a requirement for ODBC drivers and other consumers that need structured error information.

Changes

Exception.h

• Added #include <vector>.
• DatabaseException constructor now deep-copies the error vector and extracts the SQL state before the IStatus is reused.
• New public methods:
  • getErrors() — returns the error vector containing isc_arg_gds and isc_arg_number entries, terminated by isc_arg_end. String arguments are excluded to avoid dangling pointers (formatted text is already in what()).
  • getErrorCode() — convenience that returns the primary ISC error code (first isc_arg_gds value), or 0 if none.
  • getSqlState() — returns the SQL state string (e.g. "42000") if present in the original status vector, or empty otherwise.
• New private members: errorVector_, sqlState_.

Exception.cpp

• copyErrorVector() — walks the Firebird status vector and copies only safe numeric entries (isc_arg_gds, isc_arg_number), skipping string pointers that would dangle after IStatus reuse.
• extractSqlState() — extracts the isc_arg_sql_state string from the status vector while it is still valid.

src/test/Exception.cpp (new)

Seven test cases covering:

• Syntax errors produce a non-zero error code
• Error vector contains isc_arg_gds entries
• Error vector is terminated by isc_arg_end
• getErrorCode() returns the first GDS code from the vector
• SQL state is extracted for syntax errors
• Default-constructed exceptions have empty error info
• what() message is preserved

Backward Compatibility

This is a non-breaking, additive change. Existing code that catches DatabaseException and uses what() continues to work unchanged. The inherited FbCppException(const std::string&) constructor still works — the new members are value-initialized (empty vector, empty string).