It was true, but the RAISERROR statement itself never reached as the if before it resolves to FALSE...
Pay attention to the flow:
1. IF is FALSE
2. Does EXEC SP_WRITE_MESSAGE with success (can see the record in DB)
3. Does EXEC SP_WRITE_COURSE and fails. This is the point of interest... Running from SSMS I receive the expected FK violation error, running from ASP.NET (C#) I receive 'Some error message'...
And I do not prefix my stored procedures SP_ in real life, just done it here to identify them as SPs...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Which means the IF behaves differently in the two environments.
One common difference between SSMS and dotNet connection is the environment settings. The most interesting in this case is probably the ARITHABORT setting. It's normally ON in SSMS and OFF in a client connection.
Try to set ARITHABORT ON or OFF in your code to check if there is a difference in behavoiur.
I tried the link above but receiving a syntax error, my is easier then that one.
I have datetime, temperature, and humidity written in a table called tempdata.
I would like to have trigger that if value is above 65 for temperature (float), write to a different table or database called test.
Then email out when test is modified.
I've been trying phpmyadmin because I'm not good with command line.
I have phpmyadmin 4.5.4
mysql ver 14.14 distrib 5.7.20
Ubuntu mate 1.16.2
Raspberry pi 2
CREATE TRIGGER TemperatureHigh
ON RawTemperature FOR EACH ROW
IF (new.temperature > 65
INSERT INTO `test`;
Your requirements are bad. (I would presume and hope that they were made up by a teacher.)
The second two requirements can be expressed as
Req: Given today's date run a query that spans the 'prior' year based on that date.
The first requirement is incompatible with that and it is impossible to implement without other input data. One way to do that is in fact to hard code 2017 as a switch value. The second way is to presume that the target table has no data before 2017. However to implement that latter rule would mean that EVERY query would need to do a second query to determine that no data existed.
Not to mention that for users it would be confusing at least over time.
Thank you. I'm not far enough along to know how to do that just yet, but this is something I've been wanting to learn. It turns out that I was fist having cast issues because of db data type vs my C# data types did not always match appropriately, but there was also an issue with DBNull being returned in numeric types in SQLServer, which is not acceptable for C# value types.
The lack of surety in programming is part of the reason software is fragile.
The C# types are just aliases for the .NET equivalents; so long === System.Int64, etc.
I suspect the documentation is probably wrong, and the DATA_TYPE column is most likely an Int32, which can then be cast to an OleDbType value. Check the value returned by table.Columns["DATA_TYPE"].DataType to see what it's defined as.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Last Visit: 31-Dec-99 19:00 Last Update: 27-Feb-21 17:54