|
Thank you that did the trick!  thx for all the help
|
|
|
|
|
I have a series of time series data. How do I construct a SQL statement to find whether the minimum (or trough) between 2 different dates is smaller than both the values on the starting date and the ending date? My table has StockName, Date, and Price column.
The purpose of this query is to find all the stocks when their price slopes changes from negative to positive.  So if a minimum point does exists between the 2 dates but is smaller than either starting and ending values, it means there's a slope change like the following:
*................*..
..*............*....
....*........*......
.......*....*.......
.........*..........
Could you please provide a sample query statement?
Much thanks in advance!
|
|
|
|
|
Hi,
for begin point B and end point E, you could
- select all points X between B and E;
- order them by the distance between val(X) and the smallest of begin and end points = MIN(val(B),val(E));
If any record is selected, you have a V pattern, and specifying "TOP 1" would yield it.
|
|
|
|
|
Thank yuo Luc, that is pure elegancy, much better than my original idea which involves 2 separate comparisons.
Could you please let me know how to write that query statement? I currently have the following which doesn't work.... 
The time series data is stock price and I want to retrieve all the stocks with that V shape price pattern:
[Edit] Sorry for some reason when I tried to post my code, I got an error internet message and not able post the message. Could you please show me a sample of the query? I'd greatly appreciate it!
modified on Tuesday, December 29, 2009 4:04 AM
|
|
|
|
|
James Shao wrote: which doesn't work
James Shao wrote: got an error internet message
that is too vague, nobody can help you without a more accurate description.
|
|
|
|
|
Thanks for the reply Luc. Here's a more accurate discription of what my DataTable looks like:
Ticker Date Price
MSFT 1/2/2009 20
MSFT 1/3/2009 19
MSFT 1/4/2009 18
MSFT 1/5/2009 17
MSFT 1/6/2009 16
MSFT 1/7/2009 18
MSFT 1/8/2009 20
MFST 1/9/2009 21
DELL 1/2/2009 11
DELL 1/3/2009 12
DELL 1/4/2009 17
DELL 1/5/2009 17
DELL 1/6/2009 16
DELL 1/7/2009 15
DELL 1/8/2009 15
DELL 1/9/2009 14
AAPL
...
...
...
I need a query to return all the stocks with its price first going down then going up, in other words a V pattern; and the query would need to check whether this happens for a particular date. In the example above, this happened to MSFT on 1/7/2009 when the first V patter is formed.
Not sure if this can be done using SQL, but if possible, could you please help me with it? I'd be very very thankful!
|
|
|
|
|
<br />
select @minval = min(stockval) from table where stockdate between d1 and d2<br />
select @mindate = stockdate from table where stockdate between d1 and d2 and stockval = @minval<br />
This is just a starting point.
Good luck
modified on Wednesday, December 30, 2009 8:13 AM
|
|
|
|
|
Thank you djj55, a question about the query statement you wrote. Is that 2 different SQL statement, as I don't see anything between the first SELECT and the second SELECT statement. Or could you actually write a statement like that? Because I thought the @minval in the second statement is not defined....of course it's defined in the first statement, but the two statements are not connected, right?
|
|
|
|
|
Sorry for the confusion. I did notice that I did a cut & paste instead of a copy & paste so I edited my query.
There should be two queries
select @minval = min(stockval) from table where stockdate between d1 and d2;
select @mindate = stockdate from table where stockdate between d1 and d2 and stockval = @minval;
Not being a C programmer I do not normally use the semicolon which in T-SQL is not needed.
Hope this helps.
|
|
|
|
|
Hi,
I am facing some problems related to french characters. One of the character "₣" is not supported by sql server 2005. rest of the french characters is suppoeted by sql server 2005.
When ever i tried to insert data or run a select query it returns as a question mark "?".
Full text search is provided on table for search functionality.
Select doc_id,1 from DocumentMaster Where 1=1
AND (CONTAINS(Document_Filename, '"*Œ*"') OR CONTAINS(Document_Filename_French, '"*Œ*"'))
AND (CONTAINS(Document_Filename, '"*œ*"') OR CONTAINS(Document_Filename_French, '"*œ*"'))
AND (CONTAINS(Document_Filename, '"*€*"') OR CONTAINS(Document_Filename_French, '"*€*"'))
AND (CONTAINS(Document_Filename, '"*?*"') OR CONTAINS(Document_Filename_French, '"*?*"'))
i have read in couple of the site that the data type of the colum should be nvarchar or ntext for french characters to support. I even that. but then also it is not supporting the "₣" french character. Rest french character it is supporting.
please suggest any solution.
Regards,
Pranav Dave
|
|
|
|
|
Hi,
I don;t know the F-like character your message shows, and which you call a "french character".
What is its name?
Can you show us some words containing it?
do you know its unicode number?
are there things you can do with it successfully?
|
|
|
|
|
Luc Pattyn wrote: What is its name?
"French Franc", a deprecated monetary unit
Luc Pattyn wrote: are there things you can do with it successfully?
Compare beer-prices with aged Frenchmen?
I are Troll 
|
|
|
|
|
Eddy Vluggen wrote: "French Franc"
really? doesn't look anything like the symbol here[^], which is Unicode U+20A3 and should pose no problem at all.
|
|
|
|
|
Luc Pattyn wrote: really?
Yup, they're the same
Well, ehr.. the example doesn't look like that picture, but like the font that it shows below. Scroll down on that link that you sent me and the same symbol should be there in the table "Java Data". It might be that your browser is (temporarily?) set to something different than UTF-8? Or you're using a different font-set, that could also explain it's different appearance.
It shouldn't pose a problem like you said. Then again, it doesn't behave like the 'other' special characters. If I omit the N-prefix in the INSERT statement, then it will indeed put a questionmark in there. Not so for that crazy 'Œ' symbol.
I are Troll
|
|
|
|
|
yup.
the 'Œ' character (and eszet 'ß' and most accented characters used in Western languages) is part of code page 1252, whereas the French Franc and most other (possibly obsolete) monetary symbols are not.
|
|
|
|
|
Luc Pattyn wrote: the 'Œ' character (and eszet 'ß' and most accented characters used in Western languages) is part of code page 1252, whereas the French Franc and most other (possibly obsolete) monetary symbols are not.
Not even the need for a CHCP 1252, since it gets stuffed into a unicode field.
Question seems answered though, I'll wait for the repost 
I are Troll
|
|
|
|
|
Try this one;
DECLARE @TestTable AS TABLE (
TestCol NVARCHAR(2) COLLATE Latin1_General_BIN
)
INSERT INTO @TestTable VALUES (N'₣')
INSERT INTO @TestTable VALUES (N'Œ')
SELECT * FROM @TestTableCheck whether the column that you're storing data into is really accepting unicode-text, make sure the collation is set correctly, and check whether you're passing unicode or ascii as a parameter
--edit--
pranavcool wrote: i have read in couple of the site that the data type of the colum should be nvarchar or ntext for french characters to support.
That is correct. Unfortunatly, there's other places where things can go wrong. Even the value of the string that you're inspecting in the debugger is displayed using a font. The task would be to verify that SQL Server works correctly, and then to find the source of the error.
pranavcool wrote: When ever i tried to insert data or run a select query it returns as a question mark "?".
I'm guessing that this is due to the Management Studio, since you're probably not on DOS using isql. Try a small console-application, you'll see that SQL Server correctly saves and retrieves the character. That is, using the standard SqlCommand and SqlConnection.
You're not displaying the result/seeing the '?' in a browser by any chance?
Are you using MONO? Or an ODBC-driver?
I are Troll
modified on Monday, December 28, 2009 12:34 PM
|
|
|
|
|
Hi,
There was a small problem with our app where it allowed users to enter white-space only characters in one of the data fields. So now I'm trying to clean this up.
A colleague of mine sent me this unusual SQL query to find the whitespaces. The script looks like this:
SELECT tblId, ASCII(tblField1) AS 'ASCII Code', tblField1
FROM Table1
WHERE ASCII(LEFT(tblField1,1)) = 32
This query returned 40 rows.
Now, when I try either of the following:
SELECT tblId, ASCII(tblField1) AS 'ASCII Code', tblField1
FROM Table1
WHERE tblField1 = ' ' -- with a single whitespace
or
SELECT tblId, ASCII(tblField1) AS 'ASCII Code', tblField1
FROM Table1
WHERE tblField1 = '' -- empty string
The above 2 queries return 200,000+ rows.
Why is this so?
Rafferty
modified on Sunday, December 27, 2009 10:23 PM
|
|
|
|
|
Hi,
the first query selects all rows where tblField1 holds a string with a first character equal to a space.
the other two require the entire tblField1 to equal something that probably gets trimmed down to an empty string, hence returning all rows with that field empty. That obviously is quite a different query.
IMO the more elegant query would use
...WHERE tblField1 LIKE ' %'
using a single space and the wildcard character %.
|
|
|
|
|
So the = operator does not check for exact string equality... I knew before that = is case insensitive but to think that it also trims the string!
Is LIKE the more preferable conditional operator then?
Is there a performance difference between = and LIKE?
Say for example WHERE tblField1 = 'something' vs. WHERE tblField1 LIKE 'something'
Rafferty
|
|
|
|
|
1.
I'm not sure, I think it stripped the spaces, got an empty constant, and returned all records.
2.
LIKE makes most sense when it contains a wildcard, and = does not accept wildcards; without wildcards databases can take big advantage of indexing, with wildcards they can't, so most often LIKE is much slower.
|
|
|
|
|
So using LIKE will not use the database indexing even if there are no wildcards in the passed string?
Rafferty
|
|
|
|
|
I don't know what goes on inside a specific database, that is up to the guys implementing all of it; it may or may not be documented, and it might depend on circumstances, such as available memory and disk space. The simple rule is: use LIKE if you need a wildcard, and expect it to be slower.
If you need more, look for the documentation and perform your own experiments (on sufficiently large data sets).
|
|
|
|
|
hm... maybe I'll do some experimenting when I find the time.
Thanks for your help!
Rafferty
|
|
|
|
|
You're welcome.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
