I have the following query in MS Access and needs to be converted to SQL Server. I am trying to understand what does the format function do here and what is the use of "0".
SELECT Format([SumOfTotalPopulation],"0") AS Expr1 , SumOfTotalPopulation FROM
qry_ASSET_STREAM_DS_POP_PROP ;
Can anyone help me understad this. The above code is present in MS Access 2003 and Im working on SQL Server 2008 R2.
In your case, Format([SumOfTotalPopulation],"0") just removes the decimals from the number.
In SQL Server, you could use something like Str(sumOfTotalPopulation,12,0)
Or you could use Round()
The Access Format() function behaves differently based on the data type passed into it. In this example, I'm assuming that your SumOfTotalPopulation field is a number, which means that the formatting will be done as described here - basically, it will be formatted as an integer - no decimal point, no thousands separator.
The good news for you is that if the field in SQL Server is already defined as an integer type, you won't have to do this formatting. Otherwise, you should be doing this formatting at the presentation layer (user interface, web page, report, etc.) and not in the query itself.
Access teaches a lot of bad habits. Rather than translate what you have in Access one-for-one, take this opportunity to update things to be done "the SQL Server way" wherever possible.
Related
I am trying to migrate the entire backend of an Access application onto SQL Server. The first part of my project involves moving all of the tables whilst making minimum changes after the migration (no SQL Views, Pass-through queries etc. yet).
I have two queries in particular that I am using here:
ProductionSystemUnAllocatedPurchases - Which executes and returns a resultset successfully.
This is the full formula (sorry its extremely complex) for QtyAvailableOnPurchase:
QtyAvailableOnPurchase: I believe this field could be the problem here?
IIf((IIf([Outstanding Qty]>([P-ORDER-T with Qty Balance]![QTY]-[SumOfQty]),
([P-ORDER-T with Qty Balance]![QTY]-[SumOfQty]),[Outstanding Qty]))>0,
(IIf([Outstanding Qty]>([P-ORDER-T with Qty Balance]![QTY]-[SumOfQty]),([P-
ORDER-T with Qty Balance]![QTY]-[SumOfQty]),[Outstanding Qty])),0)
ProductionSystemUnAllocatedPurchasesTotal - Which gives an 'Invalid Operation' error message
Now the strange thing for me is that the first query works perfectly fine, but the second which uses the first as a source table, gives me this error message when executing. This query works perfectly fine with an access backend, but fails with SQL Server tables.
Any Ideas?
Can QtyAvailableOnPurchase be NULL? That would explain why Sum fails. Use Nz(QtyAvailableOnPurchase,0) instead.
My approach is to decompose queries. Create two queries :
First query selects needed data
Second query applies group operations (e.g. Sum)
You'll get easy way to check every step.
I have managed to find a solution to this error.
It seems that the problem is not so much with the query but rather the data type on SQL Server. SQL Server Migration Assistant (SSMA) automatically maps any Number (Double) fields to float on SQL Server. This mapping needed manually changing to Decimal.
Now according to this SO post, Decimal is the preferred for its precision up to 38 points (which is more than enough for my application), While float allows more than this, the data is stored in approximates.
Source: Difference between numeric, float and decimal in SQL Server
I was trying to convert one of my MS Access query containing format to a SQL Server view. I have my view connected to MS Access as linked tables. I was looking at this MS Access to SQL server cheat-sheet to convert Jet-SQL to T-SQL.
The cheat sheet says:
Access: SELECT Format(Value, FormatSpecification) (note: this
always returns a string value)
T-SQL: Do not do this in T-SQL;
format data at your front-end application or report
I cannot format data at my front end because the SQL Server view is linked as linked tables. I cannot have format function in tables.
The cheat sheet does not provide any explanation on why not to do this in T-SQL.
What is the reason behind not using format when converting Jet-SQL to T-SQL?
Obviously, you can format values in T-SQL using the Format function, which only has minor differences with the Access format function.
Generally, though, you shouldn't.
There are multiple reasons why it's discouraged:
Formatted strings are nearly always larger than unformatted dates/numbers, causing additional overhead when transmitting results
If you format in the application layer, the unformatted value is available to you in the application layer to validate/do calculations with/use for conditional formatting/etc. If you format in the data in the database layer, you can't do this without casting back to a date (which is a really bad practice).
If you want variable formatting based on things like locale settings, it's way easier to format in the application layer.
It's certainly not a limitation of SQL Server. It's just a bad practice to use it.
I am building a tool which displays Skype persistent chat information along with participants information. For one of the requirement, I need to filter the tblComplianceParticipant table in a given date range.
I tried many different approaches to convert tblComplianceParticipant.joinedAt column to human-readable format like 'yyyy-mm-dd', etc. but no luck so far. Data in this column are 18 digit numbers, starting with "63" for example 636572952018269911 and 636455769656388453.
These values are also not in 'windows file time' format because https://www.epochconverter.com/ldap gives the future dates with above values.
I tried looking at #JonSkeet's answer on 18 digit timestamp to Local Time but that is c# specific. I tried to replicate similar logic in SQL but no luck.
Is there any way to convert this 18 digit numbers to normal date format and perform where clause on it?
Online converter which gives desired output: https://www.venea.net/web/net_ticks_datetime_converter#net_ticks_to_date_time_and_unix_timestamp_conversion
However, I was looking for underlying logic to convert it myself as I need to perform where clause on it in SQL server stored procedure.
Our Skype administrator provided me with a SQL function (fnDateToTicks) which was part of Skype database (mgc) (Earlier, I didn't have permission so could not see it). I am verifying with him whether it is an internal IP or standard solution by Microsoft so I can share it with the larger community.
The only thing i can think is worth trying:
select CAST ([Timestamp Column] as datetime)
Which will format it as yyyy-mm-dd 00:00:00:000
This may work for SQL Server 2008 and onwards
When you use default value for a column in SQL Server Management Studio table designer, SSMS change your default and stand Parenthesis around of that (In all editions and all versions of SQL Server). For example if you set 0 as default value, this default changed to (0). I don't know why sql server use parenthesis, and is there a practical reason.
Thanks in advance.
There are certain types of objects, such as DEFAULTs and CHECK constraints that SQL Server doesn't store the original, textual form of - in contrast with, say, stored procedures, where you can (absent encryption) always retrieve it in the exact form you gave it to the server - complete with any white space, formatting, comments, etc.
Because SQL Server doesn't store the textual form, it always has to re-generate textual forms to show to users when they ask for such objects. When and where it chooses to insert parentheses can be a bit of a mystery (it's not documented) but since they don't change the meaning of the expression, they shouldn't be a concern.
Actually, 0 and (0) will evaluate to the same result, so there is nothing to really overcome. Ignore it. It's just how SQL stores them internally and a visibility issue.
It does that is you do it interactively as well. Not sure why does this , but not to worry.
My data type in database is of type money, the problem is when I save value from user entered input (via a text-box) its not what I expected.
Example : string price = "199.99"; in the table it would save as 19999,0000
I tried Convert.ToDecimal("199.99"); and Convert.ToDouble("199.99"); the result is still the same.
What sql server dataype should i use for manipulating prices oriented data.
Thanks in advance.
The result of converting a string to double and/or decimal are dependent on the locale of your system, where the C# code is running. And the value inserted into the database depends on the type of parameter passed to the database and on the local settings on the backed database server.
So, what are they? Your locale, the type of parameter, the SQL Server server/database/connection settings?
Personally, I would prefer to use DECIMAL rather than MONEY.
See these two posts on sqlblog.
It somewhat looks like the currency symbol is set to European where the comma delimited the decimals... Is this possible?