Viewing 15 posts - 56,641 through 56,655 (of 59,069 total)
Real answer is... don't use a partitioned view. SQL Server can handle huge tables.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 4:59 pm
Here's the schema you posted...
CREATE TABLE [dbo].[IISlog] (
[date] [datetime] NULL ,
[time] [datetime] NULL ,
[c-ip] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[cs-username] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[s-ip] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 4:56 pm
I still want Brian to tell us what the EXE does and how many rows per call it's going to handle.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 4:24 pm
I'm thinking in the SQL side but could probably also be done on the ASP side. In either case (sorry about the pun), financial calculations should probably not have general...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 5, 2007 at 4:15 pm
Yep... you're correct... require a particular format. I recommend TAB delimited files so that quotes and commas can be included as part of the data, if the customer desires.
And, I'm...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 10:01 pm
How'z that work Peter... sounds interesting but also sounds like it might be a cursor and I'm thinking I know you better than that... ![]()
[EDIT] Oh...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 9:49 pm
What does the EXE do?
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 9:45 pm
Macro that executes on load and reexecutes every 10 seconds should do it ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 9:44 pm
Dinendra,
First, don't even think
cursor... especially not for this size table... ![]()
The following is fully programmable...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 9:38 pm
You need to use some CASE statements, at the very least. Accounting functions are way too important to trust defaults.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 9:05 pm
Even if the perfect indexes were present, it's not likely they'd be used because of the calculations on columns in the WHERE clause... there's even a UDF in there...
"Hopefully this...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 8:51 pm
| You might also want ot learn how to use OSO-11179 naming rules |
Yep... especially when it comes to...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 8:30 pm
No such thing in SQL Server 2000. You can make one with a trigger on each table and a "LastModified" table... just be careful not to make any deadlocks...
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 8:12 pm
Some hard disk systems (SAN's, etc) come with clone and snapshot systems that will do this in scant minutes for a half-terabyte database.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 8:09 pm
There isn't one in T-SQL.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 4, 2007 at 8:08 pm
Viewing 15 posts - 56,641 through 56,655 (of 59,069 total)