Using SQRT in a Linq EF Query - sql-server-2008

I need to use the SQRT function as part of a where clause in a Linq EF query. I figured I could do this:
var qry = context.MyTable.Where("sqrt(it.field) > 1");
But it returns an error saying "'sqrt' cannot be resolved into a valid type constructor or function., near function, method or type constructor, line 6, column 5."
I had always assumed that linq literally takes what's in the where clause and translates that into a statement that is executed directly in SQL. That doesn't seem to be the case...
Anyone know the work-around?
Thanks

I don't know how you got your answer working against EF. When I tried it with EF4, it wouldn't work for me. I'd get:
LINQ to Entities does not recognize the method 'Double Sqrt(Double)' method, and this method cannot be translated into a store expression.
So after banging my head against this for a while (after all, Math.Pow(double) is supported, and SQRT is available in SQL), I realised that the square root of a value is the same as its power of a half.
So, this solution works fine.
from e in context.MyEntities
let s = Math.Pow(e.MyDouble, 0.5)
select s;
The generated SQL uses POWER instead of SQRT:
SELECT
POWER( CAST( [Extent1].[MyDouble] AS float), cast(0.5 as float(53))) AS [C1]
FROM [dbo].[MyEntities] AS [Extent1]
A simple enough workaround to a daft problem. Hope this helps someone else out.

I'm using Linq Entities and was able to do this:
testEntities entities = new testEntities ();
ObjectQuery<Fees> fees = entities.Fees;
return from f in fees
let s = Math.Sqrt((double)f.FeeAmount)
where s > 1.0
select f ;
When I check the generated SQL, I get
SELECT [t1].[TestTriggerID]
FROM (
SELECT [t0].[TestTriggerID], SQRT(CONVERT(Float,[t0].[TestTriggerID])) AS [value]
FROM [TestTrigger2] AS [t0]
) AS [t1]
WHERE [t1].[value] > #p0
This seems reasonable. I was unable to use the .Where string format to reproduce the same code, but I'm probably missing something obvious.

Check the msdn document.Entity sql doesn't support the sqrt function.

You can use System.Data.Entity.SqlServer.SqlFunctions.SquareRoot as of EF6.

Related

M expression for SSIS equivalent

I've just started exploring DAX on PowerBI; so please excuse if this query sounds too novice to expert users. DAX functions are too 'different' if coming from a SQL background, hence the query.
In SSIS I'm using a function to replace values in a column based on a string (more so, an error in the value). I'm using the below to do the job easily:
Column2 = SUBSTRING([Column1],1,FINDSTRING([Column1],";#",1) - 1)
Even after looking at the Text functions on Microsoft help page.
for almost an hour trying to understand; I couldn't for some reason.
Any ideas?
An analogous expression in M would be
Text.Middle([Column1], 1, Text.PositionOf([Column1], ";#") - 1)
But you could also use Text.Start instead since you're starting at 1 or make it even simpler with Text.BeforeDelimiter:
Text.BeforeDelimiter([Column1], ";#")
In DAX, you'd use MID/LEFT instead of Text.Start/Text.Middle and FIND or SEARCH (depending on if you need case-sensitivity or not) instead of Text.PositionOf.
LEFT ( [Column1], SEARCH ( ";#", [Column1] ) - 1 )
Either way, the logic is nearly identical but you just have different function names.

Common Table Expressions -- Using a Variable in the Predicate

I've written a common table expression to return hierarchical information and it seems to work without issue if I hard code a value into the WHERE statement. If I use a variable (even if the variable contains the same information as the hard coded value), I get the error The maximum recursion 100 has been exhausted before statement completion.
This is easier shown with a simple example (note, I haven't included the actual code for the CTE just to keep things clearer. If you think it's useful, I can certainly add it).
This Works
WITH Blder
AS
(-- CODE IS HERE )
SELECT
*
FROM Blder as b
WHERE b.PartNo = 'ABCDE';
This throws the Max Recursion Error
DECLARE #part CHAR(25);
SET #part = 'ABCDE'
WITH Blder
AS
(-- CODE IS HERE )
SELECT
*
FROM Blder as b
WHERE b.PartNo = #part;
Am I missing something silly? Or does the SQL engine handle hardcoded values and parameter values differently in this type of scenario?
Kindly put semicolon at the end of your variable assignment statement
SET #part ='ABCDE';
Your SELECT statement is written incorrectly: the SQL Server Query Optimizer is able to optimize away the potential cycle if fed the literal string, but not when it's fed a variable, which uses the plan that developed from the statistics.
SQL Server 2016 improved on the Query Optimizer, so if you could migrate your DB to SQL Server 2016 or newer, either with the DB compatibility level set to 130 or higher (for SQL Server 2016 and up), or have it kept at 100 (for SQL Server 2008) but with OPTION (USE HINT ('ENABLE_QUERY_OPTIMIZER_HOTFIXES')) added to the bottom of your SELECT statement, you should get the desired result without the max recursion error.
If you are stuck on SQL Server 2008, you could also add OPTION (RECOMPILE) to the bottom of your SELECT statement to create an ad hoc query plan that would be similar to the one that worked correctly.

Asterisk phrase variables within variables?

I have a odd situation where I would like to phrase a variable inside an SQL string. Basically ODBC will return a query with a string, in that string there will be an Asterisk variable and I need that phrased and passed back to SQL. For example (pointless code but showing the example)-
exten => s,n,Set(QUERY=${ODBC_GET_QUERY(${EXTEN})})
The SQL query in func_odbc.conf is SELECT query FROM tablea WHERE number = ${ARG1}
Now QUERY will look like to = ${DIALED}, ${DIALED} being a asterisk variable (I will make it 17005551212 for example) I need that phrased so I end up with -
exten => s,n,Set(ALLOWED=${ODBC_GET_ALLOWED(${QUERY})})
The SQL query in func_odbc.conf would be SELECT allowed FROM tableb WHERE ${ARG1} so the SQL query would resolve to SELECT allowed WHERE to = 17005551212.
Before I dive into this and re-invent the wheel, is it possible or even allowed? I have actually not tried it yet. I know in a Set() statement it will phrase a variable inline, but is there a way to phrase variable that is in a variable when its returned via ODBC? Thanks!
Please read carefully source code.
Func odbc use prepair call. So it will not work for your example just becuase prepair do not allow do that.
In general you can substitute variables. Example 1 WILL work ok.
Workaround - use mysql EXEC.

case statement in MS Access query give error

I am using below query in Ms Access. And this gives me error Syntax error in your query expression CASE WHEN not ... . Can you please tell me what I am doing wrong? In Sql Server 2008 R2, the case statement runs correctly.
SELECT TableApron.RadButtonNo, TableApron.ShortName, QueryForNot1.InspectionDate, QueryForNot1.Findings, QueryForNot1.Status, QueryForNot1.Initials, TableApron.DeptName, TableApron.Lost, TableApron.InServelDate, TableApron.RemovedDate, TableApron.PrivateUserName, TableApron.PrivateUserEmail, TableApron.ApronType, TableApron.Manufacturer
FROM TableApron LEFT JOIN QueryForNot1 ON TableApron.RadButtonNo=QueryForNot1.RadButtonNoI
WHERE (((TableApron.Lost)="N" Or (TableApron.Lost)=[#Lost]) And ((TableApron.InServelDate) Is Null Or (TableApron.InServelDate) Between CDATE([#From]) And CDATE([#To]) Or (TableApron.InServelDate)<CDATE([#To])) And ((TableApron.RemovedDate) Is Null Or (TableApron.RemovedDate) Between CDATE([#From]) And CDATE([#To]) Or (TableApron.RemovedDate)>CDATE([#To])))
ORDER BY
CASE
WHEN not TableApron.RadButtonNo like '%[^0-9]%' THEN CONVERT(int,TableApron.RadButtonNo)
WHEN TableApron.RadButtonNo like '[0-9]%' THEN CONVERT(int,SUBSTRING(TableApron.RadButtonNo,1,PATINDEX('%[A-Z]%',TableApron.RadButtonNo)-1))
END,
CASE
WHEN not TableApron.RadButtonNo like '%[^0-9]%' THEN NULL
WHEN TableApron.RadButtonNo like '[0-9]%' THEN SUBSTRING(TableApron.RadButtonNo,PATINDEX('%[A-Z]%',TableApron.RadButtonNo),9000)
ELSE TableApron.RadButtonNo
END;
The CASE statement triggers the first reported error because it is not supported in Access SQL. Use IIf() instead as #Gustav suggested.
However then you will encounter additional errors because CONVERT, SUBSTRING, and PATINDEX are also not supported in Access SQL.
Instead of CONVERT, use CInt() to cast a value to Access Integer or CLng() for Long Integer. Or you could use Val() and let Access decide which numeric datatype to give you.
Instead of SUBSTRING, use Mid().
Instead of PATINDEX, use InStr().
Assuming those suggestions eliminate the syntax errors, you may still have an issue with the Like wildcard.
If you will be running the query from the query designer or elsewhere under DAO, Access expects * instead of % as the wildcard. % is the correct wild card only when the query is run from ADO/OleDb.

what is wrong with this line of SQL?

SELECT Batch.NumStud
FROM Batch
WHERE CourseID='$courseid'
INNER JOIN Course
ON Batch.CourseID=Course.CourseID"
an error that says mysql_fetch_array(): supplied argument is not a valid MySQL result resource in <b>F:\AppServ\www\anNoECourse.php
is shown.This code was written to feed in data to a google chart.
You put SQL in wrong order (JOIN and WHERE are switched):
SELECT Batch.NumStud
FROM Batch INNER JOIN Course
ON Batch.CourseID = Course.CourseID
WHERE Course.CourseID = '$courseid'
It seems, that your query can be simplified (check your data):
select Batch.NumStud
from Batch
where Batch.CourseID = '$courseid'
I think the error is a bit more complex. Due to the fact that your SQL is invalid, you're not getting a result set. This case is not handled correctly by your PHP code!
So in addition to correcting your SQL as the others have suggested, please make sure to handle the case where you get no results or your query results in an error correctly in your PHP code!
The second part to your solution is as follows:
$result = mysql_query(...);
if ($result)
{
while (...)
...
}
This makes sure that mysql_query actually returned a result set and not false, which it does in case of errors (due to your invalid SQL code, but also in other cases). So just fixing your SQL is not enough to make your script error proof.
But again, do no longer use the mysql_.... functions! They are deprecated.