To_Char function in Oracle ,giving an error for alias? - oracle9i

This is the command,i am using in ORACLE 9i.
SELECT TO_CHAR(SYSDATE,'DD-MON-YYYY') Date FROM DUAL;
It gives an error "FROM keyword not found,Expected" ,where Date is an ALIAS,but when i enclosed
Date in "Date" double quotes like this ,it is taking it as an Alias and output is right.
Please SUGGEST!!!

Probably caused because Date is a reserved word in Oracle,
SELECT *
FROM v$reserved_words
where keyword = 'DATE'
Putting the '' around it "escapes" it so it can be used.

Use this:
SELECT TO_CHAR(SYSDATE,'DD-MON-YYYY') INTO Date FROM DUAL;

Related

How to convert TDateTime to be used in a Oracle SQL request?

I use an Oracle DB and access it using FireDAC.
I need to add to a select SQL request, two specific dates selected by the user. For that I am using two TDateTimePicker components.
I use DateTimeToStr() to convert the date from TDateTimePicker and build the SQL request like this:
FormRelatorio.FDQuery1.SQL.Add('and(PCPEDC.DTFAT) BETWEEN' +
''''+DatetoSTR(DateTimeInicial.Date)+'''' + 'and' +
''''+DatetoSTR(DateTimeFinal.Date)+'''');
Unfortunately, I get a syntax error from the DB because the DB does not accept nor auto adjust the system from month to numeral, accepting only their acronyms and in English (EX: JAN, FEB, MAR etc ...).
Is there any possibility of changing the result?
That is not a TDateTimePicker issue. It is an issue with how to pass a TDateTime (Delphi data type for date and time) to a SQL query. Currently you built a SQL string and so you must provide yourself the translation from date to string in the format accepted by the DB. This is possible but not the way to do it.
Instead, use a parametrized SQL query and FireDAC will do the work for you:
FormRelatorio.FDQuery1.SQL.Add('and (PCPEDC.DTFAT BETWEEN :InicialDate and :FinaleDate)');
FormRelatorio.FDQuery1.ParamByName('InicialDate ').AsDateTime := DateTimeInicial.Date;
FormRelatorio.FDQuery1.ParamByName('FinaleDate').AsDateTime := DateTimeFinal.Date;
This will correctly work if the columns in the database are correctly defined (You didn't showed the table structure).
If FireDAC doesn't do the correct job, you can use Oracle's TO_DATE function and Delphi FormatDateTime:
FormRelatorio.FDQuery1.SQL.Add('and (PCPEDC.DTFAT BETWEEN TO_DATE(''' + FormatDateTime('DD/MM/YYYY', DateTimeInicial.Date) + ''', 'DD/MM/YYYY') and
TO_DATE(''' + FormatDateTime('DD/MM/YYYY', DateTimeFinal.Date) + ''', 'DD/MM/YYYY'));
Oracle's TO_DATE accept a format DD/MM/YYYY and Delphi's FormatDateTime also. This avoid specifying month name.
Disclaimer: I have no Oracle DB available to check what I wrote. I did it from my head. You've got the idea...

Need to change date formate to date (YYYYMMDD) format

Here the requirement is to convert sysdate to in to YYYYMMDD in date format. Here issue it converts this in string but I need this to convert in date format in YYYYMMDD form.
select to_char(trunc(sysdate-1),'YYYYMMDD') cdr_date from dual;
Would be easier to help if you mentioned what database you were using in your post or at least your tags. However based on the to_char function you are using I am assuming oracle. If that is right then the below code should help you out. I found this by simply googling oracle date format and going to the first link which is:
https://www.techonthenet.com/oracle/functions/to_date.php
Select to_date(trunc(sysdate-1),'YYYYMMDD') cdr_Date from dual;

Query influxdb for a date

I have a table in influxdb that has a column called 'expirydate'. In the column I have afew dates e.g. "2016-07-14" or "2016-08-20". I want to select only the 2016-07-14 date, but I am unsure how?
My query is currently:
SELECT * FROM tablee where expirydate = '2016-07-14' limit 1000
But this does not work. Can someone please help me?
Assuming the value table**e** is a valid measurement...
If you are looking at selecting all of the points for the day '2016-07-14', then your query should look something like.
Query:
SELECT * FROM tablee where time >= '2016-07-14 00:00:00' and time < '2016-07-15 00:00:00'
You might also be interested in the influx's date time string in query.
See:
https://docs.influxdata.com/influxdb/v0.9/query_language/data_exploration/#relative-time
Date time strings Specify time with date time strings. Date time
strings can take two formats: YYYY-MM-DD HH:MM:SS.nnnnnnnnn and
YYYY-MM-DDTHH:MM:SS.nnnnnnnnnZ, where the second specification is
RFC3339. Nanoseconds (nnnnnnnnn) are optional in both formats.
Note:
The limit api could be redundant in your original query as it is there to impose restriction to the query from returning more than 1,000 point data.
I had to force influx to treat my 'string date' as a string. This works:
SELECT * FROM tablee where expirydate=~ /2016-07-14/ limit 1000;

Using a DateTime as paramter in stored procedures, conversion failed

I have created a stored procedure that takes a single DATETIME as its input parameter. When I try to pass in a date in the format of MM-DD-YYYY OR YYYY-MM-DD I get the error
Conversion failed when converting date and/or time from character string.
The date I am testing with is 2010-01-01 and if I take that and plug it right into the select statement from the stored procedure it woks fine. What do I have to do to use a DATETIME as a parameter?
Here is my code:
CREATE PROC dbo.WSL_ProjectSearchByDate
#param1 DATETIME --Search Date
AS
SET NOCOUNT ON;
DECLARE #STMT NVARCHAR(MAX)
SET #STMT =
'SELECT project AS Project,
project_desc AS Description
status_gl AS Status
FROM dbo.PJPROJ WITH (NOLOCK)
WHERE crtd_datetime >= ' + #param1 + '
OR lupd_datetime >= ' + #param1 + ';';
EDIT: I am fully aware this is not best practice to be using dynamic SQL, I don't have any say in the matter and this question is not about the merits of dynamic SQL and whether or not I should be using it. This is how I have been instructed to build my stored procedures and so I am doing that.
Change the parameter type to VARCHAR and add quotes to your dynamic SQL:
...
#param1 VARCHAR(10) --Search Date
...
WHERE crtd_datetime >= ''' + #param1 + '''
OR lupd_datetime >= ''' + #param1 + ''';';
or -
Apply a CONVERT to your parameter when constructing your dynamic SQL:
...
WHERE crtd_datetime >= ''' + CONVERT(VARCHAR, #param1, 120) + '''
OR lupd_datetime >= ''' + CONVERT(VARCHAR, #param1, 120) + ''';';
Various settings (language, date format) only influence how the DateTime is shown to you in SQL Server Management Studio - or how it is parsed when you attempt to convert a string to a DateTime.
There are many formats supported by SQL Server - see the MSDN Books Online on CAST and CONVERT. Most of those formats are dependent on what settings you have - therefore, these settings might work some times - and sometimes not.
The way to solve this is to use the (slightly adapted) ISO-8601 date format that is supported by SQL Server - this format works always - regardless of your SQL Server language and dateformat settings.
The ISO-8601 format is supported by SQL Server comes in two flavors:
YYYYMMDD for just dates (no time portion); note here: no dashes!, that's very important! YYYY-MM-DD is NOT independent of the dateformat settings in your SQL Server and will NOT work in all situations!
or:
YYYY-MM-DDTHH:MM:SS for dates and times - note here: this format has dashes (but they can be omitted), and a fixed T as delimiter between the date and time portion of your DATETIME.
This is valid for SQL Server 2000 and newer.
If you use SQL Server 2008 or newer and the DATE datatype (only DATE - not DATETIME!), then you can indeed also use the YYYY-MM-DD format and that will work, too, with any settings in your SQL Server.
Don't ask me why this whole topic is so tricky and somewhat confusing - that's just the way it is. But with the YYYYMMDD format, you should be fine for any version of SQL Server and for any language and dateformat setting in your SQL Server.
The recommendation for SQL Server 2008 and newer is to use DATE if you only need the date portion, and DATETIME2(n) when you need both date and time. You should try to start phasing out the DATETIME datatype if ever possible.
So in your concrete case, try this:
CREATE PROC dbo.WSL_ProjectSearchByDate
#param1 DATETIME2(0) --Search Date
-- #param1 DATETIME2(0) -- or use this, if you really only care about DATE - no time portion
AS
SET NOCOUNT ON;
SELECT
project AS Project,
project_desc AS Description
status_gl AS Status
FROM
dbo.PJPROJ
WHERE
crtd_datetime >= #param1
OR lupd_datetime >= #param1;

Datatype mismatch when querying DBase Date field via a Delphi ADO Query

I'm trying to resolve a bug in a archaic reporting tool that generates SQL dynamically and I'm running to a problem where I get a Data type mismatch error when the generated SQL queries a Date field from a Dbase table.
I've managed to replicate the same problem in a simple test app where the below query is loaded into a TADOQuery and activated.
SELECT *
FROM [QPERFSAL.DBF] QPERFSAL
WHERE ( QPERFSAL.PERFDATE = '21/01/2014' )
its obviously related to the date formatting but I've tried numerous formats but I still get the error
e.g. dd/mm/yyyy, mm/dd/yyyy, yyyy/mm/dd etc.
The obvious fix would be to used parameterised queries but as this is generated on the fly by a report tool, I can't use parameters :(
Is there something I'm missing or can I specify the date format at the ADO connection?
Thanks!
VFP OleDB Provider I believe also recognizes the DATE() function where you don't need to worry about yyyy-mm-dd or mm-dd-yyyy or dd-mm-yyyy formats. It will build into a proper date format column.
where QPERFSAL.PERFDATE = date( 2014, 1, 21 )
Now, if the "perfDate" column is that of a date/time, then you need to compare based on the date-only portion of the date/time field by using TTOD() (time-to-date function)
where TTOD( QPERFSAL.PERFDATE ) = date( 2014, 1, 21 )
Try to use as follows:
SELECT *
FROM [QPERFSAL.DBF] QPERFSAL
WHERE ( DTOC(QPERFSAL.PERFDATE) = '01/21/2014' )
Firstly, thanks to all that posted suggestions.
Alas, I tried them all but without success :(
thankfully, I found the solution while searching for something unrelated.
SELECT *
FROM [QPERFSAL.DBF] QPERFSAL
WHERE PERFDATE = Format('2014/12/06',"YYYY/MM/DD")
I'm not sure what effect this will have on localization but at least I can get the query to run now.

Resources