I've come across a bit of code that is used to validate a number inputted.
It uses a percentage sign but is nothing to do with any LIKE or varchar functions - it is doing some sort of calculation but I cannot figure it out.
Essentially it looks like this: 1 % 11
If the second number is bigger than the first it will always bring back the first, but if the second is less than the first it brings back strange results.
Does anyone know what this function is doing?
It is modulo operator (division remainder). See MSDN for details.
Related
I've got stuck on some mathematical action that I perform in SQL Server 2016 Enterprise.
I need to calculate this expression:
(4.384 / 4.2989 * 100) * 98.8251017928029 / 100
In SQL I get the result 100.78141988869389772850690000
But when I calculate this expression in MS Excel, I get: 100.7814199585120000
Since these results is a Consumer Price index, the numbers after the decimal point do matter.
So, my question is, which result is correct? SQL Server or Excel.
PS. I have updated my question.
Here is dbfiddle
Thank you.
I found same problem here: Wrong calculation in SQL-Server
I've also tried the calculation with java, and it shows the result of the excel is more accurate.
You should use decimal in calculation using sql.
Actualy, creating DbFiddle I found errors in cast. So when errors was fixed the result now the are almost the same as in excel. There is small difference in results but the difference is behind my needs of scale
I have tried looking for answers online, but I am lacking the right nomenclature to find any answers matching my question.
The DB I am working with is an inconsistent mess. I am currently trying to import a number of maintenance codes which I have to link to a pre-existing Excel table. For this reason, the maintenance code I import have to be very universal.
The table is designed to work with 2-3 digit number (time lengths), followed by a time unit.
For example, SERV-01W and SERV-03M .
As these used to be added to the DB by hand, a large number of older maintenance codes are actually written with 1 digit numbers.
For example, SERV-1W and SERV-3M.
I would like to replace the old codes by the new codes. In other words, I want to add a leading 0 if only one digit is used in the code.
REPLACE(T.Code,'-[0-9][DWM]','-0[0-9][DWM]') unfortunately does not work, most likely because I am using wildcards in the result string.
What would be a good way of handling this issue?
Thank you in advance.
Assuming I understand your requirement this should get you what you are after:
WITH VTE AS(
SELECT *
FROM (VALUES('SERV-03M'),
('SERV-01W'),
('SERV-1Q'),
('SERV-4X')) V(Example))
SELECT Example,
ISNULL(STUFF(Example, NULLIF(PATINDEX('%-[0-9][A-z]%',Example),0)+1,0,'0'),Example) AS NewExample
FROM VTE;
Instead of trying to replace the pattern, I used PATINDEX to find the pattern and then inject the extra '0' character. If the pattern wasn't found, so 0 was returned by PATINDEX, I forced the expression to return NULL and then wrapped the entire thing with a further ISNULL, so that the original value was returned.
I find a simple CASE expression to be a simple way to express the logic:
SELECT (CASE WHEN code LIKE '%-[0-9][0-9]%'
THEN code
ELSE REPLACE(code, '-', '-0')
END)
That is, if the code has two digits, then do nothing. Otherwise, add a zero. The code should be quite clear on what it is doing.
This is not generalizable (it doesn't add two zeros for instance), but it does do exactly what you are asking for.
Got me flummoxed!: I have a function that I call...
SELECT UNIT
FROM POWER_ASSETS.[dbo].[returnbaseload] ('03-12-2015','EUR')
WHERE C_TIC = 'LSE:SOE'
The function "returnbaseload" queries values from a view and does some calcs with the values. Simple. It returns 29 rows.
If I open it up in a new SQL query tab, copy n paste... it returns 533 rows.
If I copy and paste from new tab back to old tab.... 29 rows.
Any ideas? Got me beat.
P.S have also tried putting
Use POWER_ASSETS
GO
just in case there was a duplicate table accidentally created somewhere in the master...
I am worried because I am calling the function eventually from a vb program and am getting the wrong amount of rows from the sql query in vb. That's what got me investigating... the right amount of rows was from the new tab, 533 rows.
There's no way a deterministic select fetches different result sets when using the same parameters. Period.
As comments indicates you must being overloking or missing something.
1 - Be sure both panes are using the same.
[SERVER/INSTANCE].[DATABASE].[SCHEMMA].[TABLE]
it's by far the most common scenario.
It also is valid for function/SP calls. Be sure you are calling the same object and not a different version of it.
2 - Be sure both are using the same user/privileges.
Maybe you are using different connection parameters
.
3 - Be sure there's no implicit convertion messing with your query.
You are using some sort of varchar to date convertion here. Be sure you got the same settings (collation, copy from a unicode to a UTF-8 archive, etc.) in both tabs. Also you can try to query the table using some sort of GETDATE() function instead of dealing with that varchar literal.
4 - Be sure your data is not changing while you query it.
Stop the server and put it in single user. Maybe your data is just being updated.
5 - Be sure there are not any random function in the query.
Sometimes we got funny BL and someone unintented put some rand logic in it.
6 - Be sure you are not just drunk or tired.
Once I and a friend where working for like +20hrs no stop. He got angry with a buggy "dot" in the screen. Turned ou it was a actual bug (a fly) and also tried to get rid of it with the mouse pointer.
Calm down and call a friend to get a look on it.
I am trying to run an IF statement in Google Spreadsheet that will, if "Yes" SUM a series of values.
=IF(G3="Yes",=SUM(C3*D3)+(E3*D3))
This works (if I ignore the IF) and just do =SUM(C3*D3)+(E3*D3), so I know my math is correct.
I have read a few different posts that are asking similar questions, but many have "guesses" and are offering different structured formulas, so I'm not really even sure what the proper structure is any more.
Basically, for the nerdy portion of you, the spreadsheet does the following:
If the "killed" column is Yes, I need to calculate the XP of the monsters killed.
Base XP (C3) times Qty (D3), plus Bonus XP (E3) times Qty (D3) and them SUM the value.
The equal sign (=) in front of SUM should not be there. If your formula works I guess Google Docs just ignores it. Also, the function SUM() is useful to add the values from a range of cells from the same row or column when you don't know in advance how many cells you will add (or there are more than 2 cells and you use SUM() because it's less to write).
If I understood your request, the formula you need is:
=IF(G3="Yes",C3*D3+E3*D3)
Right now the SUM function is only wrapping C3*D3 then you are adding (E3*D3). This is the same as (C3*D3)+(E3*D3) not using the SUM function. Order of operations tells us there is no need for the parentheses so you could write C3*D3+E3*D3.
The IF function has the following parameters:
IF(EVALUATION,IF TRUE,IF FALSE)
So your final equation would be:
=IF(G3="YES",C3*D3+E3*D3,"")
I always add the FALSE return to be blank so that if I need to change it later I can do so.
I don't have much experience so I apologize in advance for a potentially dumb question. I did not create these tables nor the queries that have been used in the past. With that said --
For the past several months I have been using a date conversion query that was given to me to update columns from an integer to a date. It used to work just fine and I swear everything is the same for my latest data extractions, but at some point the dates started getting wonky. For example, a typical date column might look like:
58222
58158
59076
58103
And the conversion query looks something like this:
IIf([D_posting]<>0,[D_posting]-18261,0)
And returns the above dates as:
05/27/2059
03/24/2059
09/27/2061
01/28/2059
Which obviously is wrong. The situation kind of reminds me of how I remember we generated random numbers in C++ (which was a long time ago), but for the life of me I can't figure out how to reverse engineer the correct subtraction factor without a reference point.
I also tried using the CDate() function instead, and it resulted in a bunch of future dates also, leading me to wonder if there's something else wrong. I work for a small physicians group so it might be something in the Electronic Health Records software, but I'd like suggestion on what I should check to make sure it's nothing that I've done.
You could create a query that uses the 'cdate' function (see below) to return the date. You can modify the code so that it subtracts the offset (maybe 18261?)
In the immediate window of VBA you can tinker with the following:
The 'cdate' will take a number and convert it to a date:
?cdate(41925)
10/13/2014
The 'cdbl' will take a date and convert to a number.
?CDbl(Date())
41926