Using Oracle Discoverer 11g
I'm trying to create a report that would generate certain dates. For example
The column would be called Date and the only results I would like to come back are from the current date minus 20 months (assuming 600days). So 20 months back until the current date. Is this possible?\
So far, I am here and can't figure out how to write the 20 months back:
units.Date(SYSDATE, 'DD-Mon-YY - ???)
I was placing this under Tools > Edit Calculations
Let me know if you guys need any more information.
Update: I went ahead and tried this, but recieved this error. Not sure what i means.
It sounds like from your post that you want the time between today and the unit.date time. Meaning, that if your unit.date was 1/1/2015 and today is 4/14/2015, then your calculation would return "103" days. Assuming my interpretation is correct, then you should just enter the following as your calc:
TRUNC(SYSDATE) - TRUNC(units.date)
The EUL_DATE_TRUNC will format the date to a specified format, which I don't think is needed for your calculation.
Related
It seems that a query of mine returns wrong results, and I'm not sure why. I don't yet rule out the possibility that the SQL is actually doing something else then what I expect/want it to do since I haven't used SQL for a time now.
I post it here because I'm kind a stuck with the why it returns wrong results sometimes.
The error is in the MIN(FIRM.account_recharge.X__INSDATE) (or at least the ones I noticed)
SELECT
FIRM.customer.CUSTOMER_ID,
FIRM.customer.CORPORATION,
FIRM.customer.CUSTOMER_NAME_PREFIX,
FIRM.customer.CUSTOMER_NAME,
FIRM.account.ACCOUNT_TYPE,
FIRM.account.ACCOUNT_TYPE,
FIRM.customer.LANGUAGE,
FIRM.customer.VALIDATED,
FIRM.account.X__INSDATE,
SUM(FIRM.account_recharge.GROSS_VALUE) SUM_FELTOLTESEK,
MIN(FIRM.account_recharge.X__INSDATE),
INNER JOIN FIRM.account
ON FIRM.customer.CUSTOMER_ID = FIRM.account.CUSTOMER
INNER JOIN FIRM.customer_address
ON FIRM.account.CUSTOMER = FIRM.customer_address.CUSTOMER
INNER JOIN FIRM.account_recharge
ON FIRM.account.ACCOUNT_ID = FIRM.account_recharge.ACCOUNT
GROUP BY FIRM.customer.CUSTOMER_ID,
FIRM.account.X_INSDATE,
FIRM.customer.CORPORATION,
etc,etc
HAVING MIN(FIRM.account_recharge.X__INSDATE) BETWEEN to_date('2014-JAN. -01','YYYY-MON-DD') AND to_date('2014-DEC. -31', 'YYYY-MON-DD');
This code should return information abut our customers, their sum account 'recharging'/'replenishing'/'paying in' , sorry not sure of what word to use here. and their first payment/money upload to their account in 2014. Yet sometimes the return values seems to just ignore the actual first time our client paid in money, and shows the second or third date. (my random manual check returned that around 1/10 of the time the returned values are wrong.)
A costumer of ours can have more the one account linked to him. I'm using Oracle SQL developer (4.0.0.12) please ask if you would like to know anything else about this pickle im in.
Otherwise It seems to work nicely, but if you have any other tuning tip, I would be glad to hear them.
Thank you for your help!
HAVING MIN(FIRM.account_recharge.X_INSDATE) BETWEEN '14-JAN. -01' AND '14-DEC. -31'
This is definitely incorrect. You are comparing dates. so, you must convert the string literal explicitly into a date using TO_DATE and proper format mask.
For example,
HAVING MIN(FIRM.account_recharge.X_INSDATE)
BETWEEN to_date('2014-JAN-01','YYYY-MON-DD')
AND to_date('2014-DEC-31', 'YYYY-MON-DD')
Also, do not use YY to denote the year. You don't have to re-invent the Y2K bug again. Always use YYYY format for an year. Else, if you are stuck with YY values for year, then use RR format. But, I would insist, always use YYYY format for year.
PostgreSQL provides the date format datatype to store dates. The problem with these dates is however they can't - as far as I know - reason about uncertainty.
Sometimes one does not know the full date of something, but knows it happened in January 1995 or in "1999 or 2000" (date2). There can be several reasons for that:
People don't remember the exact date;
The exact date is fundamentally unknown: for instance a person was last seen on some day and found death a few days later; or
We deal with future events so there is still some chance something goes wrong.
I was wondering if there is a datatype to store such "dates" and how they are handed. It would result in thee-valued logic for some operations like for instance date2 < 20001/01/01 should be true, date2 < 2000/01/01 be possible and date2 < 1998/01/01 should be false.
If no such datatype is available, what are good practices to construct such "table" onself?
There are several different ways to approach fuzzy dates. In PostgreSQL, you can use
a pair of date columns (earliest_possible_date, latest_possible_date),
a date column and a precision column ('2012-01-01', 'year'), or
a range data type (daterange), or
a varchar ('2013-01-2?', '2013-??-05'), or
another table or tables with any of those data types.
The range data type is peculiar to recent versions of PostgreSQL. You can use the others in any SQL dbms.
The kind of fuzziness you need is application-dependent. How you query fuzzy dates depends on which data type or structure you pick. You need a firm grasp on what kinds of fuzziness you need to store, and on the kind of questions your users need answered. And you need to test to make sure your database can answer their questions.
For example, in legal systems dates might be remembered poorly or defaced. Someone might say "It was some Thursday in January 2014. I know it was a Thursday, because it was trash pick-up day", or "It was the first week in either June or July last year". To record that kind of fuzziness, you need another table.
Or a postmark might be marred so that you can read only "14, 2014". You know it was postmarked on the 14th, but you don't know which month. Again, you need another table.
Some (all?) of these won't give you three-valued logic unless you jump through some hoops. ("Possible" isn't a valid Boolean value.)
To add to what Mike posted I would use date comments such as:
date Comment
-------------------------------------------------------------------
1/1/2010 Sometime in 2010
7/8/2014 Customer says they will pay the second week in July
1/1/2015 Package will arrive sometime next year in January
Also, you can use date parts. Create a separate column for the Year, Month, and Day. What ever in unknown leave it blank.
I don't have much experience so I apologize in advance for a potentially dumb question. I did not create these tables nor the queries that have been used in the past. With that said --
For the past several months I have been using a date conversion query that was given to me to update columns from an integer to a date. It used to work just fine and I swear everything is the same for my latest data extractions, but at some point the dates started getting wonky. For example, a typical date column might look like:
58222
58158
59076
58103
And the conversion query looks something like this:
IIf([D_posting]<>0,[D_posting]-18261,0)
And returns the above dates as:
05/27/2059
03/24/2059
09/27/2061
01/28/2059
Which obviously is wrong. The situation kind of reminds me of how I remember we generated random numbers in C++ (which was a long time ago), but for the life of me I can't figure out how to reverse engineer the correct subtraction factor without a reference point.
I also tried using the CDate() function instead, and it resulted in a bunch of future dates also, leading me to wonder if there's something else wrong. I work for a small physicians group so it might be something in the Electronic Health Records software, but I'd like suggestion on what I should check to make sure it's nothing that I've done.
You could create a query that uses the 'cdate' function (see below) to return the date. You can modify the code so that it subtracts the offset (maybe 18261?)
In the immediate window of VBA you can tinker with the following:
The 'cdate' will take a number and convert it to a date:
?cdate(41925)
10/13/2014
The 'cdbl' will take a date and convert to a number.
?CDbl(Date())
41926
I'm trying to filter out and report records in a database that fall between a specified date range. I'm there are other threads here on how to do something similar, but my dates are stored as date timestamps (which is why I think the issue is arising)
My current query is as follows:
"SELECT * FROM JOURNAL WHERE Date_Time>'10/10/2013 00:00:00'"
(Note that journal is the name of the table I'm pulling the data from and date_time is the field in which the date is stored. I'm aware the query doesn't quite do what I want it to yet, but I was just testing out a simpler case at first.)
When I run this query (as part of an excel macro), excel reports that it can't find any records even though I know their are records past this date. Does anyone know how to do this properly?
Edit: I've got it, it was an issue unrelated to the query (something else in the macro) Thanks so much for the help (changing the date format worked)
have you tried other date format? like this:
"SELECT * FROM JOURNAL WHERE Date_Time>'2013-10-10:00:00:00'"
A simple between statement is what you need:
SELECT * FROM JOURNAL WHERE Date_Time between '10/10/2013 00:00:00' and '[otherdate]'
You need to run this to check for one important thing: If the server is running the BETWEEN as inclusive or not. If it's inclusive, both dates are included. If not, the range will begin either before or after one or both.
I've seen SQL servers that are the same in every respect actually treat this condition differently. So it's a good idea to check that.
What is the best way to group dates by day or month in solr queries ?
For example if I have the date in the following format: 20140108180854746 (actually the format doesn't matter all that much here, might as well be in a normal format), is there an easy way to just group by its days or months.
Someone suggested keeping a field just for the days that it will group by and the other solution I saw was something in the lines of
&group=true&group.func=rint(div(ms(date_dt),mul(24,mul(60,mul(60,1000)))))
which isn't exactly user friendly but it will do the trick I guess.
Any general advice about that?
There are in-built faceting methods to accomplish this. You can use the "facet.date.gap" param to achieve this. Take a look at the following example.
q=solr&facet=true
&facet.date=j_createddate
&facet.date.gap=+1DAY,+2DAY,+3DAY,+10DAY
Here, we define date faceting for j_createddate, a date field. Then we create compartments for the gaps 1 days, 2 days, 3 days and 10 days
Refer http://solr.pl/en/2010/08/23/the-scope-of-solr-faceting/ & http://wiki.apache.org/solr/SimpleFacetParameters#facet.date.gap