Sean

Any ideas? Has anyone tried this approach on SQL 2008?

thanks

Thanks for the all your responses and the acticle.

Remember that if you execute the package “in context of the server” thus via SQL Agent (scheduled job) you need to give the account under which the SQL Agent is running access to the folders where you are trying to access files/data.

Remember that just because you might have access to a network resource doesn’t mean that the account that executes the package does.

Phil

I’ve encountered the exact problem you’ve described but even using the UNC path has not helped. Is there somethin else I might be missing like a specific package proctection level or something?

Is there a way in qroup policy to apply Launch Permissions on MsDtsServer component to include the Distributed COM (DCOM) user group. I have found everytime I apply SQL Server patches it gets reset to default. I thought if Group Policy controlled it, I would not have to reapply this everytime I installed s SQL patch.

Thanks

Thanks,
Phil

(For those reading along, the page Todd’s referring to is the “Integration Services Data Types” page.)

I suppose from a taxonomy perspective that page is no different than any other that has those terms in them. With that said, we have a page that contains definitions, and as such, in the “library” source refinement category, definition pages should carry more weight than kb articles, white papers, etc… Perhaps.

Also, with that said, a more proper search could be “ssis data types,” (where your page returns as #1) but then you shouldn’t *have* to make a “broad” search like that when all you want is to search by one data type.

Note: Actually, for me, Google returned that page as #12 in the list. Google is a funny thing - consistent results it does not provide. (And this may be based, in part, on click statistics and/or my logged-in Google profile, region of the country, who knows…)

The DT_TEXT case is a weird one for two reasons:

1. the best page is a “group” page– there’s no page for “DT_TEXT” alone. This is unusual for MSDN– we almost always try to give “API” pages (where there’s a specific keyword you use to look it up) their own page, partially to make it easier for seach engines to find a single “best” page to correspond to that API/Keyword’s name.

2. some documents in the SSIS docs contain “(SSIS)” in the title and some don’t. Live Search, at our request, prioritizes words in the title very high for MSDN content so we can get the best match for class names, method names, language keywords, etc. which are always in the title

So an optimization for words-in-titles which usually helps actually hurts in this case.

I’m following up with the Live Search team about this problem to see if they have a good idea for how to fix this. If Live can’t fix it, I’ll pass on the feedback to the SQL Documentation team that they might want to consider putting that disambiguator (e.g. SSIS) in all their documents, not just ones which have duplicate titles elsewhere in SQL documentation.

If you run into other cases where relevance isn’t what you like, or you have a suggestion or bug report for MSDN Search, feel free to post at our forum: http://social.msdn.microsoft.com/forums/en-US/SearchFeedback/threads/

Thanks,
Justin Grant
MSDN