Has anyone dealt with handling database errors in GORM?
I have two cases in my code where I need to exploit a database error: constraint or UUID validation.
(e.g. SQL Error [8169] [S0002]: Conversion failed when converting from a character string to uniqueidentifier.)
When I use the GORM model-find or raw-scan methods, I get the expected results in positive run, but in negative run result.error doesn’t include a SQL error (result.Error is nil), e.g. when I try to insert against a constraint or get with nonvalid UUID. I get this error in the SQL console with the same query.
On the other hand, when I use exec (also sql.Exec), I get an adequate error on a negative run, but the result of the positive run does not contain (or I can’t find) the expected value.
Does anybody have an idea?
Related
I am running a jdbc query and using the result set to retrieve column values.
My output goal is a csv.
I am using Jython scripting in Maximo via the automation scripts.
I notice that I frequently get errors writing lines out and in the middle of output I get missing or truncated values from the point of error.
The errors read basically:
BMXAA7837E - An error occured that prevented the BIALOCHIERREP script for the BIALOCHIERREP launch point from running.
UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0' in position 16: ordinal not in range(128) in at line number 224
psdi.util.MXApplicationException: BMXAA7837E - An error occured that prevented the BIALOCHIERREP script for the BIALOCHIERREP launch point from running.
It seems logical that some data coming in from the database is not UTF-8 if I am seeing this error
I know that other processes such as BIRT are able to read this very same data and get by the 'errors'
So is there a recommended way of getting by this or determining for sure whether the data is good or bad in the source database? I am currently somewhat immersed in trying to find the bad data using debug statements.
Since you are running SQL directly against the database, I would check whether your database has cast() or convert() functions you can call to do that conversion to ascii for you.
I am trying to call a DB2 Stored Procedure which has two Input parameters (Timestamp, both) and one Output parameter (Integer). I am trying to do so from JMeter JDBC Sampler and getting sql syntax exception.
Response code: 42884 -440
Response message: com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-440, SQLSTATE=42884, SQLERRMC=PROCEDURE;DEVSCHEMA.GET_ROW_COUNT, DRIVER=4.19.26
Response headers:
1272084586, URL=jdbc:db2://<db2IP>:<port>/DB2T, UserName=<someUserName>, IBM Data Server Driver for JDBC and SQLJ
From IBM Documentation I got to know that this error happens when either Stored procedure is not present - which is not the case, Schema name incorrect - which is also not the case, mismatching number of parameters - I verified this but I am doubtful at this point because JMeter provides separate fields to be filled up and in one of the fields I might be passing incorrect value.
I have not much knowledge of JMeter but with the help from apache JMeter documentation I have set below values to the Sample Fields.
Query Type: Callable Statement
Query: CALL DEVSCHEMA.GET_ROW_COUNT(?,?,?)
Parameter Values: ${__time(yyyy-MM-dd HH:mm:ss,)},${__time(yyyy-MM-dd HH:mm:ss,)},0
Parameter Types: IN TIMESTAMP,IN TIMESTAMP,OUT INTEGER
Variable Names:VARCOUNT
Handle ResultSet: Store as a String
Can anyone please figure out where am I making a mistake? Many thanks.
The issue has been resolved. It was literally something else about which I never gave a thought. When I got the same error when I tried to access the same SP using Java code, I contacted DB2 team who wrote the Stored procedure. And issue was with the SP. According to them execute access was given so after drilling here and there they preferred to create a new SP which worked without any issues. Else everything was perfect from JMeter side.
I have a massive stored procedure that I did not write. It's about 10K lines long. Part of it creates a few temp tables, inserts some records into these tables, then goes through about 8,000 lines of validation and removes invalid records from the tables and re-inserts them into a temp Error table for reporting back to the user.
Somewhere along the lines, I get the following SqlException in my C# code:
Conversion failed when converting the varchar value 'AAAAAAAABA683' to data type int.
But if I shorten the value down to just A683 or something, the procedure runs as expected and just marks this particular record as an error. So it sounds to me like it's not actually a problem with the data types, but something else.
Unfortunately the LineNumber property of the SqlException I catch doesn't help me, since I don't have access to seeing the actual SQL being executed. I can only look at the procedure itself.
Has anyone encountered something like this before?
When I get this error, it is because I am using + as a string concatenation operator, but one (or more) of the arguments is an integer. By the rules that SQL Server uses, if any argument is an integer, then the + is treated as addition rather than string concatenation.
Unfortunately, with a 10,000-line stored procedure you have few options (there could be a diatribe here about software engineering, making code more modular, and using constraints to validate data, but that would not be helpful).
What can you do? I don't actually know. You have a bug in your code, in the sense that the stored procedure is not expecting the types of values you are providing (and all the more ironic because it sounds like most of the procedure is validating values). Some logic in the stored procedure is changing the shorter value to something acceptable for numeric conversion, perhaps something like substring(val, 2, 5) and expecting the value to be an integer.
You could prevent the error by using the concat() function for string concatenation in the stored procedure rather than +. However, that might just hide some other error in the code. You could also prevent the error by pre-validating the data and preventing certain rows from being passed in.
I am performing a DB2 load, and I am struggling to understand the impact of using GeneratedOverride over IdentityOverride. When I run the following command:
db2 load from tab123.ixf of ixf replace into application.table_abc
All rows are rejected, with the following error being the culprit:
SQL3550W The field value in row row-number and column column-number is not NULL, but the target column has been defined as GENERATED ALWAYS.
So to try and step around this, I executed
:
db2 load from tab123.ixf of ixf modified by identityoverride replace into application.table_abc
But this immediately returned this error:
SQL3526N The modifier clause "IDENTITY OVERRIDE" is inconsistent with the current load command. Reason code: "3".
From checking the reason code I see that the issue is "Generated or identity related file type modifiers have been specified but the target table contains no such columns." .. but the SQL3550W error seems to infer that the columns are generated always!
The only way I can get these rows to commit to the table is to run..
db2 load from tab123.ixf of ixf modified by generatedoverride replace into application.table_abc
Can anyone enlighten me to why I am recieving the SQL3526N error, or what the implications of running generatedoverride are?
Thanks for sticking with me..
Generated columns are not necessarily identity columns, apparently that's the case in your situation. Check the CREATE TABLE syntax to see what are other ways to generate column values.
By using the GENERATEDOVERRIDE option during the load you are obviously replacing (overriding) the generated values with those from the input file.
I am getting a "SQL Server Error: arithmetic exception, numeric overflow, or string truncation" error
here is the code below
AQuery:= TSQLQuery.Create(nil);
with AQuery do
begin
SQLConnection:- AConnection;
SQL.Text:= 'Insert into.....';
ParamByName('...').asString:= 'PCT';
.
.
.
try
ExecSQL;
finally
AQuery.Free;
end;
end;
I have alot of ParamByName lines, and I can't figure out which one is throwing the exception. I just know its thrown on the ExecSQL line. How can i tell which paramByName is causing the error?
When you have the metadata of the table, check the maximum length of string fields. When debugging, check the length of the strings you feed the parambynames. Also check the type of numeric fields, and make sure you don't exceed a maximum value. (I had this problem once with a string which length exceeded the varchars length in the table, and had this problem with a smallint databasefield that I tried to set to a too high value)
Get the SQL text after param substitution and run it as a query in SQL Server management studio.
You'll be able to debug it from there.
You are trying to insert a string value into a field that is not big enough to hold the value. Check the length of the values you are inserting against the length of the field in the table.
As others have said, it's almost certainly that you are pushing too-large a string into one of your fields. It could also happen with numeric values but it's most likely to be a string.
I'd suggest you temporarily alter each of your ParamByName('').AsString:=blah lines with a text constant, eg;
ParamByName('surname').AsString:='Smith';
ParamByName('firstname').AsString:='John';
etc, and see if you get an error. If it goes through without an error, then your problem is most likely to be that one of your string parameters is too long. Check your table schema and debug the actual strings you are putting into the parameters.
Depending on how much access (and experience) you have with this, you might find it more helpful to turn on the SQL Server logging such that you can see your queries (and the contents of those parameters) when the get processed by the SQL server. This will show you exactly what string and numeric values are actually being given to the server.
Which version/edition of SQL Server are you using?