Using integer math, 8 divided by 16 equals 0 (with a remainder of 8), and 0 multiplied by $2 is still 0. In this case, both operands (8 and 16) are integers. The problem here is that SQL Server keeps intermediate results in the same data type as the operands in an equation. At 16 ounces, Bob will owe your company $2 at less than 16 ounces, he'll owe nothing.
Now, increase the package weight to 16 ounces. This code's result shows that Bob gets his package delivered for free (.0000). SELECT = 8 -Bob's package weighed 8 ounces
To calculate how much to charge a customer named Bob for delivering his 8-ounce package, you might use a SELECT statement like this: SELECT package_weight / 16 * $2.00īob should owe $1, right? You can use the following script to run a quick check of this answer without even creating a table: DECLARE int You store the package weight in ounces as an integer in your database. Let's say your company charges $2 per pound to deliver small packages. Related: Mapping T-SQL Data Types to SqlTypes Let's look at some of these behaviors and how you can keep them under control. Some SQL Server data types-including integer, character, numeric, datetime, and uniqueidentifier-also behave in ways that might surprise you. Have you ever walked toward a door, pushed hard to open it, and- pow!-slammed right into it? The door opened the other direction, of course. Sometimes things just don't work the way you expect.
0 kommentar(er)
