[MS SQL 2005] bulk load werkt niet voor specifieke user

[Milmoor]

Wat zie ik over het hoofd?

Test query

code:

Execute as user = 'bulkload'
Declare @File VARCHAR(200)
Set @File='testbestand.htm'
exec ('SELECT * FROM OPENROWSET(BULK ''' + @File + ''', SINGLE_CLOB) AS htm')

Foutmelding
Msg 4834, Level 16, State 1, Line 1
You do not have permission to use the bulk load statement.

Zonder de execute as werkt het wel, maar die heb ik juist nodig om een user die dit recht niet heeft via een stored procedure voor een specifieke situatie wel die mogelijkheid te geven: http://www.sommarskog.se/grantperm.html#execascaller

Gevolgde oplosrichting
De server rol bulkadmin: http://stackoverflow.com/a/13002720

Ingestelde rechten

[ Voor 38% gewijzigd door Milmoor op 19-04-2015 17:21 ]

[Milmoor]

Hmmm, ik zie nu dat de default schema anders is afhankelijk van via welke route je kijkt (dbo vs bulkload). Het lijkt wel of de server role de user niet helemaal goed kent. Daar heb ik al eerder wat gedonder mee gehad. Ik ga hem opnieuw aanmaken.

[edit]
Opnieuw aangemaakt. Dat helpt helaas niets. Er was en is trouwens geen schema bulkload. Deze staat nu overal op dbo.

[ Voor 20% gewijzigd door Milmoor op 19-04-2015 18:14 . Reden: Getest ]

[Milmoor]

Geen briljante ideeën?

[Feanathiel]

Voer je dit uit via een stored procedure, of gewoon los vanuit de management studio (of code, kan ook natuurlijk)? In sommige gevallen wordt de gebruiker buitensgesloten.

[DamadmOO]

Ik heb nu even geen ms sql bij de hand, maar werkt alles wel als je zelf met je bulkload account inlogt? Als het dan wel werkt dan kan het zo zijn dat je ook nog je impersonate moet instellen,

[Milmoor]

Feanathiel schreef op maandag 20 april 2015 @ 21:20:
Voer je dit uit via een stored procedure, of gewoon los vanuit de management studio (of code, kan ook natuurlijk)? In sommige gevallen wordt de gebruiker buitensgesloten.

Dit bericht heb ik vanochtend gemist met mijn slaperige kop. Ik draai dit nu vanuit een query window. Jouw link ziet er veel belovend uit qua oorzaak. Ik ga dit met onze database man bespreken. Ik kan de gevolgen van op trustworthy zetten niet overzien. Het alternatief met certificaten hoop ik juist te vermijden. Want dan moet bij elke aanpassing een nieuw certificaat gekoppeld worden. Niet fijn qua beheer/onderhoud en helemaal niet fijn in de ontwikkelfase.

DamadmOO schreef op maandag 20 april 2015 @ 23:23:
Ik heb nu even geen ms sql bij de hand, maar werkt alles wel als je zelf met je bulkload account inlogt? Als het dan wel werkt dan kan het zo zijn dat je ook nog je impersonate moet instellen,

Ga ik testen. Maar dan had ik verwacht dat hij had gezegd dat ik niet mocht impersonaten. Dat wil zeggen: ik ga ervan uit dat de execute as de impersonate is.

[ Voor 97% gewijzigd door Milmoor op 21-04-2015 11:57 . Reden: netjes gequote en missend antwoord doorgenomen ]

[Milmoor]

Rechtstreeks inloggen als bulkload en het werkt wel. Het zit puur in de execute as. Helaas niet oplosbaar zonder of de beveiliging te verminderen (database Trustworthy maken) of een overkill aan beveiliging toe te voegen (signature gebruiken). Ik heb het gelukkig een heel andere workaround kunnen verzinnen: scheduled job. Deze doet zijn ding en zet de keten daarna weer in beweging. Vereiste wat wel wat ombouwen en het vertraagd de keten van acties, maar het is veilig en het werkt. Bedankt voor het meedenken.