September 29, 2008 at 2:25 pm
I have a table with 800,000 records that we need to test if the generated name that the records should point to actually exists.
I was hoping to use xp_fileexist to test each record to see if it exists and return the values alongside the file... declare the whole mess as a CTE and then pull some statistics from it.
I'm running into a stumbling block trying to join to a extended stored proc... so I thought instead I would execute the extended stored proc in a user defined function.
That isn't working either
CREATE FUNCTION dbo.file_exists (@filenam as varchar(max))
RETURNS @tabexist TABLE (fileexist int,fileisdir int,parentexist int)
AS
BEGIN
INSERT INTO @tabexist EXEC master..xp_fileexist @filenam
RETURN
END
Gives back
Msg 443, Level 16, State 14, Procedure file_exists, Line 5
Invalid use of side-effecting or time-dependent operator in 'INSERT EXEC' within a function.
Any other ideas?
September 29, 2008 at 9:22 pm
Yep... but I need to know... do you expect that all of the file names are going to be in the same directory, or not?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 30, 2008 at 7:55 am
Jeff Moden (9/29/2008)
Yep... but I need to know... do you expect that all of the file names are going to be in the same directory, or not?
No the files will all be in the same root path... but they're going to be by \\root path\ (company code)\year\month\day\filename.ext
That's why I was hoping to get by with using a fuction so I could cross apply it...
September 30, 2008 at 11:28 am
Ummm... ok... can you use xp_CmdShell or sp_OA* routines?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 30, 2008 at 12:37 pm
Jeff Moden (9/30/2008)
Ummm... ok... can you use xp_CmdShell or sp_OA* routines?
I can if I must... I'd rather avoid them...
September 30, 2008 at 1:19 pm
Heh. Now this is one of the few things that SQLCLR is good for. It is fairly easy to write a SQLCLR Function with EXTERNAL_ACCESS rights to do this for you.
On the other hand, it might be faster to just scan the whole file structure's directory tree into a table and then compare/test the file names by referring to that table.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
September 30, 2008 at 1:28 pm
I just noticed:
CREATE FUNCTION dbo.file_exists (@filenam as varchar(max))
RETURNS @tabexist TABLE (fileexist int,fileisdir int,parentexist int)
AS
BEGIN
Declare @Exists int
Set @Exists = 0
--INSERT INTO @tabexist EXEC master..xp_fileexist @filenam
EXEC master..xp_fileexist @filenam, @Exists OUTPUT
Insert into @tabexist(fileexist) Values(@Exists)
RETURN
END
I think that this will work just fine.
Of course, with only one value returned, you may want change it into a scalar function.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
September 30, 2008 at 7:21 pm
rbarryyoung (9/30/2008)
Heh. Now this is one of the few things that SQLCLR is good for. It is fairly easy to write a SQLCLR Function with EXTERNAL_ACCESS rights to do this for you.
Nah... 😛 No SQLCLR... you just proved it. :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
September 30, 2008 at 7:39 pm
Mark... you showed the naming convention for the directories... what's the naming convention for the file names and extensions themselves?
--Jeff Moden
Change is inevitable... Change for the better is not.
October 1, 2008 at 8:31 am
Jeff Moden (9/30/2008)
Mark... you showed the naming convention for the directories... what's the naming convention for the file names and extensions themselves?
The file names are (in/out) + recipientid + .zfx
The in/out depends on the table it's coming from.
October 1, 2008 at 9:38 am
Crud... I was hoping they were unique so we could use xp_Dirtree to solve your problem very easily. xp_FileExists is not available in SQL Server 2k8 like it is in 2k5... but, xp_Dirtree is.
As a sidebar, if you look it up on the internet, most folks don't know about the wonderful "3rd parameter". Rather than explain, try it with an without the 3rd parameter...
EXEC Master.dbo.xp_Dirtree 'C:\',3 --Produces a list of directories 3 levels deep.
EXEC Master.dbo.xp_Dirtree 'C:\',3,1 --Produces a list of directories 3 levels deep AND a list of file names
--Jeff Moden
Change is inevitable... Change for the better is not.
October 1, 2008 at 12:37 pm
Neither of them seem to like UNC paths either... :/
I had read that xp_fileexists was supposed to work nicely with UNC's... since it hates mapped drives... but alas...
October 1, 2008 at 8:43 pm
Dunno about that, Mark... I've never had a problem with xp_DirTree and UNC's. If SQL Server can see it, xp_Dirtree can read it in my humble experiences.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2008 at 8:37 am
If I remember right the account running the SQL Agent is used to access the UNC...
Since we lock our service accounts down tighter than drums... likely it doesn't have the rights to that share and it will take an act of god to get it permission.
Ah well 🙂 thanks everybody.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply