I am working on legacy code which was written in slick 2.1 (can't upgrade right now).
val query = foo.filter(x => x.d >= input._1).filter(x => x.d < input._2)
println(query.selectStatement)
query.list
I can see that this generate the query
select x2.`a`, x2.`b`, x2.`c`, x2.`d` from `foo` x2 where (x2.`d` >= {ts '2016-07-30 00:00:00.0'}) and (x2.`d` < {ts '2016-07-30 23:23:59.0'})
when this executes, it gives an error java.sql.SQLSyntaxErrorException: ORA-00911: invalid character
When I copy paste this printed query into Oracle query editor it gives the same error there. However if I remove all the ```s then it works. Why is slick 2.1.x generate bad query? is there anyway to tell it to stop generating "`"s
I found the answer. I had imported the wrong driver. I had imported MySQLDriver and was trying to execute the code against Oracle.
Importing the right OracleDriver (via slick-extensions) generated the right query.
Related
I am trying to compare the date modified (field type: Timestamp) with a value that is based off of a month before the current date. I keep getting a syntax error when using the function DateAdd().
I Am Using Libreoffice base 6.2.3.2 (x64) and firebird 3.0 embedded
Using this code, I get a result returning no records but no error
Select *
From "tblPart"
Where "Date Modified" = Current_Timestamp
but anytime I want to use the Dateadd() function, I get an error
Select *
From "tblPart"
Where
"Date Modified"< Dateadd(Month,-1,Current_Timestamp)
Expected to Return a list of results that have been modified over a month ago.
Errors:
SQL Status: HY000
Error code: 1000
Syntax error in SQL statement
SQL Status: HY000
Error code: 1000
SQL Status: HY000
Error code: 1000
syntax error, unexpected $end, expecting BETWEEN or IN or SQL_TOKEN_LIKE
//EDIT: Added the programs that I used
I ran into the same problem. Though the SQL-statement with DateAdd() has been suggested as working, LO Base answered the query with a message box
Syntax error in SQL statement
Why it should work
In contrast the same SQL statement like in the query succeeded by running it in the "Execute SQL Statement" window (LO Base' main window menu "tools" > "SQL…").
Solution
What finally got my query to work was to check "Run SQL command directly" in the toolbar or in the "Edit" menu.
This prevents LO from analyzing the SQL query before execution. This fails, because it is not understanding the full SQL statement (firebird's DateAdd()-function), and thus is the reason for the mentioned errors.
I have the following Expression to concatenate two columns
Expression<String> stringConcat =
criteriaBuilder.concat(criteriaBuilder.concat(rootPr.get(ProductList_.prodDesc), " # "),
rootEmp.get(ProductEmp_.empNo));
and it used in CriteriQuery in the followng manner,
criteriaQuery.multiselect(root.get(ProductCatalogue_.userId),
root.get(ProductCatalogue_.productList),criteriaBuilder.selectCase()
.when(criteriaBuilder.equal(root.get(ProductCatalogue_.prodId),"ZCX"), stringConcat)
.otherwise(rootPr.get(ProductList_.prodDesc)));
However when SQL is generated, it is throwing error
missing right parenthesis
because in if else part of SQL has a question mark as it is expecting a parameter
THEN (t0.prodDesc = ?)
How to resolve this problem?
This is an EclipseLink bug, that was fixed in version 2.4.2.
Upgrade to a newer version, and it will work (tested on EclipseLink 2.5.2).
I have this Linq To Entites query below. When I execute this query from a Console Application, it produces SQL and executes perfectly.
But when I execute it from a web application, I get an error message that says the Min() function is not recognized by Linq To Entites and it cannot be translated to a store expression.
It is EXACTLY the same query. Both project have the same settings (concerning EF 6) in their config files, and they reference the same assemblies.
from ce in db.CustomEvents
where ce.fld_start > DateTime.Now
group ce by ce.fld_ownerId into g
select new
{
fld_ownerId = g.Key,
next_appointement_date = g.Min(i => i.fld_start)
}
It seems this happens only when the Min aggregate is on DateTime property. I hadn't this issue when I had Min on decimals, for instance.
The error message I get when I execute this in the web site is this
LINQ to Entities does not recognize the method 'System.Nullable`1[System.DateTime]
Min[CustomEvent](System.Collections.Generic.IEnumerable`1[CustomEvent],
System.Func`2[CustomEvent,System.Nullable`1[System.DateTime]])'
method, and this method cannot be translated into a store expression.
But when I execute it from the Console app, it successfully generates the SQL statement below
SELECT
1 AS [C1],
[GroupBy1].[K1] AS [fld_ownerId],
[GroupBy1].[A1] AS [C2]
FROM ( SELECT
[Extent1].[fld_ownerId] AS [K1],
MIN([Extent1].[fld_start]) AS [A1]
FROM [dbo].[mtbl_CustomEvent] AS [Extent1]
WHERE [Extent1].[fld_start] > (SysDateTime())
GROUP BY [Extent1].[fld_ownerId]
) AS [GroupBy1]
Does anyone have a clue on what is happening?? Why the same query generates SQL when run in the console app, but fails with an exception when run in the web site??
UPDATE:
It seems that the problem was an ambiguity between two different implementations of Min<T>(this IEnumerable<T>) (.net's implementation, and our own implementation). Removing the "using OurLibrary;" namespace from the file fixed the problem.
After vittore's suggestion to use extension methods syntax we found that the problem was that in the web project we referenced one of our libraries that included an implementation of Min<T>(this IEnumerable<T>), and we also had the using OurLibrary.Namespace; directive in the file where the linq query was.
When we used the linq syntax, the compiler picked our implementation of Min for the query and did not throw any errors. Then, at runtime, the LINQ to Entities framework crashed because it could not recognise our implementation of Min.
from ce in db.CustomEvents
where ce.fld_start > DateTime.Now
group ce.fld_start by ce.fld_ownerId into g
select new
{
fld_ownerId = g.Key,
next_appointement_date = g.Min()
}
Here there was no compiler error.
But when we used the extension method syntax, the compiler stopped with an ambiguity error, and that's how we identified the problem.
db.CustomEvents
.Where(ce => ce.fld_start > DateTime.Now)
.GroupBy(ce => ce.fld_ownerId, ce => ce.fld_start)
.Select(g => new { g.Key, next_appointement_date = g.Min() })
Here the compiler threw an error of ambiguous call to .Min
It's weird that the compiler does not recognise the ambiguity in the Linq syntax. After all, linq is only syntactic sugar.
I'm using Subsonic 2.1 and I'm having an error with the next query:
SqlQuery queryResTitle = new Select(
new Aggregate(ResTitle.ResourceTitleIDColumn, "ResourceTitleID", AggregateFunction.GroupBy),
new Aggregate(ResTitle.ResourceTitleColumn, "ResourceTitle", AggregateFunction.GroupBy),
new Aggregate(VenVendor.TitleColumn, "Title", AggregateFunction.GroupBy),
new Aggregate(ResTitleStatus.StatusColumn, "Status", AggregateFunction.GroupBy))
.From(Tables.ResTitleOngoing)
.InnerJoin(ResTitleStatus.ResourceTitleIDColumn, ResTitle.ResourceTitleIDColumn)
.LeftOuterJoin(VenVendor.VendorIDColumn, ResTitle.VendorIDColumn);
I'm getting the error:
"The ORDER BY clause is invalid in
views, inline functions, derived
tables, subqueries, and common table
expressions, unless TOP or FOR XML is
also specified"
I also added .Top("1") but I still got the same error.
You should debug the generated query that SubSonic returns:
var queryString = queryResTitle.BuildSqlStatement();
and execute it in your favorite database administration tool.
Maybe you can figure out what's going wrong.
I have noticed that when we use F_RoundToEven UDF from FreeAdhocUDF, that it fails to produce a correct result with certain numbers.
For example, the query:
select
F_RoundToEven(21.145, 2) Correct,
F_RoundToEven(215.145, 2) Fail
from Rdb$Database
produces the result:
CORRECT FAIL
21.14 215.15
Obviously these two number should both resolve to .14
Has anyone else come across this problem, and perhaps found a way around it?
I am using the latest version of FreeAdhocUDF with Firebird 2.1 and it fails on both Windows 32bit and Linux 64bit.
Thanks.