I must translate a Cognos Impromptu 7 query to TSQL. Part of the query includes the following:
nconvert((SUBSTRING((ascii(t1.TargetDate)) from 1 for 4)))
/*
where:
t1 is a table alias
TargetDate is a BIGINT contains the value 200501
*/
Can someone explain the purpose of the function/expression "ascii"?
(FYI: SQL Server ASCII function produces ascii(200501) ==> ascii(2) ==> 50 )
Bonus: If someone can point me to an online resource that includes the ascii definition, that would be appreciated. My search bore no fruit.
The official Impromptu 7.5 administrator guide is in here:
Impromptu Administration Guide 7.5.0
All functions (including text, numeric and Date / Time functions) are documented here
However, I did not find any ascii function there.
So, the second option is creating an IQD file:
Viewing SQL generated by Impromptu
If this does not help. use SQL Server profiler to see the real SQL statement that impromptu sends:
SQL Server Profiler
Related
When trying to do an SQL injection on an Oracle SQL database I have the problem that most of the examples in the tutorials do not work. I already found out that I only can use CASE WHEN a THEN b ELSE c END instead of normal if statements.
The question I have now is how do I get time delay into the injection? Benchmark() and sleep() do not work either.
I already now that the table is named "flag" and the field name I want to read out is named "password".
My only information i get from the database is the time it needed to execute my input (or query since I bypass the input to inject SQL)
I found the following SQL statement on the web at SQL Injection Tutorial
select dbms_pipe.receive_message(('a'),10) from dual;
I am not certain I should be participating in this sort of thing, but since I found it with my first Google Search, I will go ahead and post it.
I tested it and it delayed the result by 10 seconds.
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'm trying the following query from the BigQuery Standard SQL documentation:
SELECT DATE_DIFF(DATE '2010-07-07', DATE '2008-12-25', DAY) as days_diff;
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#date_diff
However, I'm receiving the following error from the UI:
Error: Encountered " "\'2010-07-07\' "" at line 1, column 23. Was expecting: ")" ... [Try using standard SQL (https://cloud.google.com/bigquery/docs/reference/standard-sql/enabling-standard-sql)]
This is a simple copy and paste from the doc into the web UI Query Editor.
Any idea on how to resolve this?
Below are examples for respectively BigQuery Legacy SQL and Standard SQL
Make sure you try code as it is in answer below - not just second lines but 2(both) lines including first line that looks like comment - but in reality important part of query as it controls which SQL dialect will be in effect!
#legacySQL
SELECT DATEDIFF(DATE('2010-07-07'), DATE('2008-12-25')) AS days_diff
and
#standardSQL
SELECT DATE_DIFF(DATE '2010-07-07', DATE '2008-12-25', DAY) AS days_diff
both returns result as below
Row days_diff
1 559
Ideally, you should consider migrating to Standard SQL
Although the answer has already been provided in the comments to your questions and by Mikhail in the other answer, let me share with you a complete answer that hopefully addresses all your doubts:
ERROR MESSAGE
As explained in the error message you are getting, [Try using standard SQL (...)]. You are trying to run this sample using Legacy SQL (which instead would use the DATEDIFF function). You are actually right, you are running the exact same query provided in the documentation, but the issue here is that the documentation you are using is for Standard SQL (the preferred query language in BigQuery), but you are instead using Legacy SQL (the default language in the old UI, the one you are using).
CHANGE THE QUERY LANGUAGE IN USE
First of all, I would like to remark the importance of using Standard SQL instead of Legacy SQL, as the former adds new functionalities and is the current recommended language to use with BigQuery. You can see the whole list of comparisons in the documentation, but if you are starting with BigQuery, I would just go straight away with Standard SQL.
Now, that being clarified, in order to use Standard SQL instead of Legacy SQL, you can have a look at the documentation here, but let me summarize the available options for you:
In the BigQuery UI, you can toggle the Use legacy SQL option inside
the Show options menu. If this option is marked, you will be using
Legacy SQL; and if it is not, you will be using Standard SQL.
You can use a prefix in your query, like #standardSQL or #legacySQL, which would ignore the default configuration and use the language you specify with this option. As an example on how to use it, please have a look at the other answer by Mikhail, who shared with you a couple of examples using prefixes to identify the language in use. You should copy the complete query (including the prefix) in the UI, and you will see that it works successfully.
Finally, as suggested by Elliott, you can use the new UI, which has just recently released in Beta access. You can access it through this link https://console.cloud.google.com/bigquery instead of the old link https://bigquery.cloud.google.com that you were using until now. You can find more information about the new BigQuery Web UI in this other linked page too.
I have a stored procedure which searches by text passed by a parameter. I noticed that if the text is not in English (i.e. Hebrew, Arabic), the query finishes without returning any rows. I am sure there is data to be found
I dont know which SQL server is being used : it is whatever is provided by GoDaddy on shared Windows hosting plan.
The thing is, I have a asp.net site which can search and fetch the data from this column encoded as UTF-8. The path which does not work is the MS SQL Management Studio. Even when I manually run same stored procedures which work from inside asp.net - they dont manage to find non English characters. The parameters I pass to the query are prefixed by N qualifier.
Try using the N character like the sample :
Select * from students where name like N'%بیژن%'
and as mentioned in the comment the column data type should be Nvarchar.
The following statements return different SOUNDEX values in SQL Server 2012 while they produce the same value in SQL Server 2008:
PRINT SOUNDEX('BAKHSHI') --B200
PRINT SOUNDEX('Bakhshi') --B220
Has anyone else had this issue in SQL Server 2012 and knows how to get around it?
According to https://msdn.microsoft.com/en-us/library/bb510680.aspx:
SOUNDEX function implements the following rules: If upper-case H or
upper-case W separate two consonants that have the same number in the
SOUNDEX code, the consonant to the right is ignored If a set of
side-by-side consonants have same number in the SOUNDEX code, all of
them are excluded except the first. The additional rules may cause the
values computed by the SOUNDEX function to be different than the
values computed under earlier compatibility levels. After upgrading to
compatibility level 110, you may need to rebuild the indexes, heaps,
or CHECK constraints that use the SOUNDEX function. For more
information, see SOUNDEX (Transact-SQL)
So you might want to try following Microsoft's upgrade path advice. Also, SOUNDEX is collation sensitive - are your 2012 DB collations the same as your 2008 collations?