Viewing 15 posts - 53,656 through 53,670 (of 59,072 total)
That's probably because when you execute it from VB, you're doing it as embedded SQL... which has no chance of reusing an Execution Plan.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2007 at 8:21 am
No...
But you can write forumulas in the Excel spreadsheet that will create the necessary INSERT/SELECT or INSERT/VALUES statements.
There's also several ways to import the data from a spreadsheet into SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2007 at 8:19 am
What are you running the code from? Query Analyzer or ???
The code, as I've posted it, runs fine...
Is it possible that you've run into the same problem a lot...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2007 at 7:47 am
kenny (12/8/2007)
Wow, this is the fastest response I have ever gotten.Thanks Jeff for your assistance.
Just lucky... I happened to be "in the neigborhood" and just happened to have an answer...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2007 at 7:43 am
Jeremy,
Do you have an example of how you'd solve the above using the Pivot operator?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2007 at 7:29 am
You bet, Cali... thanks for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2007 at 7:22 am
I wish I could take the credit for the following bit of SQL prestidigitation, but I can't... thank "Sergiy" 😉
CREATE FUNCTION dbo.fnAddWeekdays (@Start DATETIME, @Days INT)
RETURNS DATETIME
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 7:01 pm
Ah, crud... I just noticed that this is a 2k5 forum... the code I posted is most definitely for 2k...
You'll need to do some mods to the code but I...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 6:59 pm
I guess the best way to help you get this sorted out, is to give you a chunk of "tool" code I made a while back... could easily be turned...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 6:26 pm
In your code, you never say...
DELCLARE @db_Name SYSNAME
That means you have an undefined variable and it's gonna give you an error. Here's the beginning of your code... and there's...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 6:13 pm
fosco (12/8/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 6:00 pm
This takes care of the single letter and blank situations...
--===== This is the solution for the known constraints on the data as posted
DECLARE @MaxWidth TINYINT
SET @MaxWidth...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 5:55 pm
Drat... both of ours come up with a little problem when we have data like this...
--===== This just creates demonstrable test data and is NOT part of the solution
SET NOCOUNT...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 5:15 pm
The following is your guide... the rest is dependent on your "Yukon DBA" knowledge of T-SQL 😉
http://www.sql-server-helper.com/tips/read-import-excel-file-p03.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 12:54 pm
...or, perhaps, something a bit more "auto-magic"... 😀
--===== This just creates demonstrable test data and is NOT part of the solution
SET NOCOUNT ON
DECLARE @TestData TABLE(String VARCHAR(10))
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2007 at 11:14 am
Viewing 15 posts - 53,656 through 53,670 (of 59,072 total)