August 13, 2013 at 1:46 pm
I'm having trouble diagnosing what the issue is here, i'm not sure the error message that i'm getting is useful in helping find it out. Am using SSMS.
I've successfully created the linked server per:
http://msdn.microsoft.com/en-us/library/aa746379.aspx
and i know i'm using a correct LDAP connection string, as we use the same one in several web apps that work well.
I have also had my network admin check my string and he indicated that it looked correct to him.
My select syntax has been tested against both forms:
a) LDAP://DC=Fabrikam,DC=com
b) LDAP://Fabrikam.com/DC=Fabrikam,DC=com
(note my querystring is different than that above, but same form)
and either query parses just fine.
However, all i get in return
Msg 7321, Level 16, State 2, Line 1
An error occurred while preparing the query "SELECT name
FROM '<LDAP STRING>'
" for execution against OLE DB provider "ADsDSOObject" for linked server "ADSI".
replace <LDAP STRING> with a or b forms.
I know it's not a permissions issue as I'm using the current security context, and I can open up in ADMINISTRATIVE TOOLS and see what I"m looking at. (using ASDI Edit)
But i'm stuck as to what to check next.
I've checked at a bunch of places and most are a regurgitation of the original article above, and indicate i'm headed the correct way....
Thoughts on what i can try to get over this 'speed bump' i'm facing? Heck even getting a different error message would excite me at this point... (current problem related of course....)
August 13, 2013 at 7:23 pm
i guess my other option is to create a table to hold the data and then use powershell to pull and push the data in. I'd rather not have this extra step if possible. thoughts anyone?
August 13, 2013 at 7:37 pm
I know nothing about this but I'll ask a question. Have you tried your query using the ADSI LDAP dialect mentioned in the MS article?
I'd love to hear how you got this to work.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
August 13, 2013 at 10:57 pm
Can you please post your query?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
August 14, 2013 at 12:20 pm
all generated the same error in SSMS. dialect didn't matter.
SELECT * FROM OPENQUERY( ADSI,
'SELECT name
FROM ''LDAP://DC=sfcc,DC=spokane,DC=cc,DC=wa,DC=us''
')
SELECT * FROM OPENQUERY( ADSI,
'SELECT name
FROM ''LDAP://DC=sfcc,DC=spokane,DC=cc,DC=wa,DC=us''
')
SELECT * FROM OPENQUERY(ADSI,
'<LDAP://sfcc.spokane.cc.wa.us/DC=sfcc,DC=spokane,DC=cc,DC=wa,DC=us>')
SELECT * FROM OPENQUERY(ADSI,
'<LDAP://DC=sfcc,DC=spokane,DC=cc,DC=wa,DC=us>')
August 14, 2013 at 1:28 pm
Query looks ok, but I would try adding a WHERE ObjectCategory = 'Person' or whichever you need
I would also try setting the security context to your authentication just to be sure it is working properly (assuming that's the account you are testing with). I know it sounds bizarre but I've had a similar issue in the past and although had specified to use current security context, it was executing as a different user...
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
August 14, 2013 at 1:31 pm
will try that. i do know that i had the where clause on there with same results, so was just trying to simplify the most i could. thanks!
August 14, 2013 at 1:41 pm
interesting. The two open queries using TSQL and openquery now work with a 'forced' security context. The two LDAP dialect queries still do not work.
still... THANK YOU!!!! i'm at least moving forward. nothing i hate more than being stuck and going.... 'hmmm... not sure what the problem is'
How did you solve this issue, as this dataset will need to be made using the current security context. (checking to make SURE that is the case though)
R
August 14, 2013 at 2:38 pm
Is this going to be running via an Agent job or something?
______________________________________________________________________________Never argue with an idiot; Theyll drag you down to their level and beat you with experience
August 14, 2013 at 5:34 pm
It's looking like it's going to be a very specific context (which i'm still working on running down), and the current security context won't be used (still not sure why that didn't work for that selection, but did when forced supposedly same user), but no it's going to be used in creating a set of views that will get all staff and faculty users out of four distinct AD servers. It will then be joined with 2 other sources to complete the information.
This will replace an outmoded data source that was not successfully kept up to date due to a very poor pattern of necessary user inputs.
We're attempting to take a lot of the 'people updating' out of the equation, so that updates happens in a single way, and roll into the data, and not the current several unsuccessful ways, that either don't get done because of lack of knowledge or laziness.
What i'll have to test next is, which is faster, if either, to create 4 separate views (for the 4 ad servers), or if a union of 4 open queries achieves the same results in speed.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply