Viewing 15 posts - 58,216 through 58,230 (of 59,067 total)
Yep, you're right on the setting of the variable... but hopefully every one realizes that was just to demo. The rest shouldn't be a problem as I used fixed formats...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2006 at 4:30 am
I like "simple" when I can get away with it
... here's my take on the date part thingy...
--===== Create a...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2006 at 2:50 pm
By using some "JBM PFM"... this is actually a programable converter in that you can program the number of significant digits just by changing the contents of a single variable......
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2006 at 1:47 pm
You can find out if they are spaces or characters that look like spaces (assuming that all the rows for a given column have leading spaces)...
SELECT ACSII(LEFT(columnname,1))
FROM yourtable
If the come...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2006 at 11:13 am
| For that query, we will need a calendar table with a search condition like... |
Senthil,
Joe is absolutely correct about...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2006 at 11:51 pm
Using Noeld's example, the EXEC statement might look like this...
EXEC (@str1+@Str2)
Yeah... I know about xp_executeSQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2006 at 5:57 pm
| Ok... let's hope Business Objects has a cross-tab function |
If it doesn't, post back 'cause...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 17, 2006 at 7:06 am
I guess that means you may have more or less than the 4 parts you mentioned in your first post, eh?
Ok... let's hope Business Objects has a cross-tab function (or not,...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 17, 2006 at 6:53 am
Thanks for the compliment but I'm no God of SQL
... even after 11 years with SQL Server, I still make some really...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 16, 2006 at 4:28 pm
Dionisis,
I'd say your function has a bit of a bug in it...
SELECT dbo.fn_GetNumber('123-456')
It choked on that pretty hard, I'd say. The problem is that ISNUMERIC allows the "+", "-",...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 16, 2006 at 7:01 am
>>Thank you for your input. parse name does not work because the values are not as concistent as we want to have
Ummm... post some real data and let us...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2006 at 9:50 pm
| Finally, so data trolls still use o-sql...great to know there is still a hard-core... |
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2006 at 9:06 pm
If I may make an additional suggestion... it is not necessary to store the data in a Duration column... you could simply make a calculated column consisting of the the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2006 at 8:30 pm
Steven,
See the post that "SQL Junky" directed you to... the bottom line is ISNUMERIC is not an ISALLDIGITS function... ISNUMERIC allows all sorts of "garbage" in...
Your CASE statement should be...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2006 at 9:12 am
Using your current table structure, you could do this...
INSERT LogTime (EmployeeID, CompanyID, LogIn, LogOut,
DaysTotal,HoursTotal,MinutesTotal,SecondsTotal)
SELECT @EmployeeID, @CompanyID, @login, @Logout,
DaysTotal = X.Sec / (24 * 60 * 60),
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2006 at 8:40 am
Viewing 15 posts - 58,216 through 58,230 (of 59,067 total)