I'm designing a DS JOB targeting a SybaseIQ and realize that IfthenElse Syntax and DI Decode() function are not getting pushed down to the database server.
Is there any equivalent DI function that I can use to push the whole operation down to Sybase IQ server ?
Apparently DS BODI won't be able to convert ifthenelse function to SybaseIQ's SQL format query if the database type is set to SybaseIQ in the datastore's setting.
If I change the database type to ODBC then the next thing I have to do is to change the option ifthenelse support to Yes and voila, the operation will be pushed down to SQL Server. Unfortunately, I'm not allowed to edit the datastore's setting ... so I think I will have to cope with this until this issue is fixed by SAP then.
Related
CREATE TEMPORARY FUNCTION
s2id(lit FLOAT64,
low FLOAT64,
level FLOAT64)
RETURNS STRING
LANGUAGE js AS """
return litLowToId(lit,low,level);
"""
OPTIONS
(library="test.js");
Big query is highlighting the lit part without telling me why. It just says encountered "" in line 2. What is happening here?
Big query is highlighting the lit part without telling me why. It just says encountered "" in line 2. What is happening here?
The reason you are getting above error in UI is because you are using Legacy SQL
Switch to Standard SQL (uncheck Use Legacy SQL checkbox in Options Panel [in Classic UI] or check Standard SQL dialect radiobox [in new UI] )
Alternatively you can just add below line to the very top (as a first line) of your whole code
See Enabling Standard SQL for more details
#standardSQL
In addition you have to provided a valid path - something like below
library="gs://my-bucket/path/to/test.js"
And finally, you need to have actual query below your function
How do I convert this standard sql to legacy sql code in bigquery?
I strongly recommend you to stay with BigQuery Standard SQL
In case you you locked by existing legacy sql code - you might rather want to migrate your sql query from legacy to standard instead
In any case UDF for BigQuery legacy and standard dialect are quite different - see Differences in user-defined JavaScript functions
I am trying to execute a query against a CSV file using OleDbConnection, OleDbCommand and the Microsoft.Jet.OLEDB.4.0 driver but keep getting an exception saying no value given for one or more required parameters. I suspect the problem is in the SQL query syntax (I am trying to use the same queries I use with SQL Server) but I can find no manual to check it (another thing I would like to know is how exactly to address the columns if there is no header in the CSV file). Do you happen to know where is the SQL dialect I need described?
Jet 4.0 uses a dialect based on ANSI SQL 92. Source: http://support.microsoft.com/kb/275561/en
Regarding the exception, your wondering of how to address columns is probably related, particularly if you have a WHERE clause checking a value in a column. If there is no header row, and the connection string has "HDR=NO" in the Extended Properties, you need to refer to the columns as F1, F2, F3, and so on in order from left to right. Source: http://support.microsoft.com/kb/316934
I am wondering if anyone can explain why I get different results for the same query string between using the ExecuteSQL function in FM versus querying the database through a database browser (I'm using DBVisualizer).
Specifically, if I run
SELECT COUNT(DISTINCT IMV_ItemID) FROM IMV
in DBVis, I get 2802. In FileMaker, if I evaluate the expression
ExecuteSQL ( "SELECT COUNT(DISTINCT IMV_ItemID) FROM IMV"; ""; "")
then I get 2898. This makes me distrust the ExecuteSQL function. Inside of FM, the IMV table is an ODBC shadow, connected to the central MSSQL database. In DBVis, the application connects via JDBC. However, I don't think that should make any difference.
Any ideas why I get a different count for each method?
Actually, it turns out that when FM executes the SQL, it factors in whitespace, whereas DBVisualizer (not sure about other database browser apps, but I would assume it's the same) do not. Also, since the TRIM() function isn't supported by MSSQL (from what I've seen, at least) it is necessary to make the query inside of the ExecuteSQL statement something like:
SELECT COUNT(DISTINCT(LTRIM(RTRIM(IMV_ItemID)))) FROM IMV
Weird, but it works!
FM keeps a cache of the shadow table's records (for internal field-id-mapping). I'm not sure if the ExecuteSQL() function causes a re-creation of the cache. In other words: maybe the ESS shadow table is out of sync. Try to delete the cache by closing and restarting the FM client or perform a native find first.
You can also try a re-connect to the database server via the Open File script step.
HTH
I'm looking for a way to programmatically execute arbitrary SQL commands against my DB.
(Hibernate, JPA, HSQL)
Query.createNativeQuery() doesn't work for things like CREATE TABLE.
Doing LOTS of searching, I thought I could use the Hibernate Session.doWork().
By using the deprecated Configuration.buildSesionFactory() seems to show that doWork won't work.
I get "use lacks privilege or object not found" for all the CREATE TABLE statements.
So, what other technique is there for executing arbitratry SQL statements?
There were some notes on using the underlying JDBC Statement, but I haven't figure out how to get a JDBC Connection object from Hibernate to try that.
Note that the hibernate.hbm2ddl.auto=create setting will NOT work for me, as I have ARRAY[] columns which it chokes on.
I don't think there is any problem executing a create table statement with a Hibernate native query. Just make sure to use Query.executeUpdate(), and not Query.list() or Query.uniqueResult().
If it doesn't work, please tell us what happens when you execute it, and join the full stack trace of the exception and the SQL query you're executing.
"use lacks privilege or object not found" in HSQL may mean anything, for example existence of a table with the same name. Error messages in HSQL are completely misleading. Try listing your tables using DatabaseMetadata - you have probably already created the table.
I'm working on a legacy product and i have some SQL being executed through ADO, to an Access database with linked tables to SQL Server. I'm getting the error 'Undefined function 'Round' when i execute the SQL but if i take the query and run directly in Access it works fine. I know that EVERYTHING is correct and that this is a machine specific issue since this is production code, it works on other machines and has been deployed successfully for many clients.
I'm not even sure where to begin to be honest. I'm running the correct (latest) versions of Jet/ADO/MDAC.
ANY help would be appreciated.
Thanks in advance.
EDIT: Obviously, the SQL includes the aggregate function 'Round'. I'm aware of the differences between Jet and SQL implementations. This problem is due to some problem with a component on my machine and NOT with the code. The SQL executes properly when done through MS Access 2007 but NOT through ADO.
EDIT2: Right solution from the comments:
shahkalpesh: If it executes fine thru Access, it could be that Access has the DLL available to it, which has the Round function. What is the connection string, you are using?
Stimul8d: I'm not sure how it can be anything so do with the connection string. This code works on EVERY other machine, with no changes; just not on mine.
Andomar: Well, that's your problem right there, your machine is farked up. You can still install vb6 sp6 maybe.
Stimul8d: Well, SP6 fixed it. Cheers Anndomar, no idea why SP6 fixed it but it did!
EDIT: Based on your comment this newsgroup post might be the answer:
Unfortunately, when you are running
queries from outside of Access (as you
are from VB), your only connection to
the database is through the Jet
engine, which doesn't know anything
about most VBA functions. There's no
way around this, other than to return
the data to your VB application and
use the functions on the data there.
And two posts later:
I solved the problem. Updated my VB
with the Service Pack 6... it took
care of the problems.
Old answer here:
Try FLOOR() instead of ROUND().
To round something to the nearest integer, you could:
declare #floatmyboat float
set #floatmyboat = 1.51
select floor(#floatmyboat+0.5)
P.S. Maybe post the exact error you get. If it's "The round function requires 2 to 3 arguments.", that means Sql Server is borking on the ROUND().
The round() function exists in SQL Server as well.
The only difference is: in Access the precision is an optional parameter, but in SQL Server you have to specify it.
So this will only work in Access, but not in SQL Server:
select round(Column) from Table
This will work in Access and SQL Server:
select round(Column,1) from Table
it could be that Access has the DLL
available to it, which has the Round
function
ACE/Jet uses share expression services with VBA. Broadly speaking, ACE/Jet supports as expressions all VBA5 functions (as distinct from methods) whose arguments and return values are scalar types (e.g. no arrays, no objects). The Round() expression falls into this definition and indeed is available to ACE/Jet with the same semantics as its VBA function equivalent. As anyone familiar with the ACE/Jet engine should know, though, the semantics can differ from the VBA equivalents e.g. ACE/Jet ANSI-92 Query Mode SQL
SELECT TYPENAME(ROUND(5, 1))
returns 'Long', whereas VBA
?Typename(Round(5, 1))
returns 'Integer'.
In other words, Round() wasn't going to be the problem here.