[MSSQL/FoxPro] DTS package schedule failed

Pagina: 1
Acties:

  • Pelle
  • Registratie: Januari 2001
  • Laatst online: 16:31

Pelle

🚴‍♂️

Topicstarter
Ik moet wat informatie uit een Visual FoxPro table-file trekken om te kunnen gebruiken op een intranet. Op de server (Windows 2000 Server, MSSQL 2000) heb ik de Microsoft Visual FoxPro OLE DB Provider geinstalleerd, en vervolgens heb ik met de 'Import data' wizard in MSSQL een DTS package gebouwd.
Het enige wat die package doet, is de FoxPro table-file uitlezen, en de gegevens 1 op 1 overzetten in een import-tabel. Het runnen hiervan gaat goed, na het aanmaken maar ook bij het handmatig starten. Echter, als ik de package wil schedulen (dagelijks moet die import gedaan worden namelijk), dan failed de betreffende job.

Als ik dan de job-history bekijk, dan krijg ik niet zoveel informatie:
The job failed. The Job was invoked by Schedule 13 (Import MI053001). The last step to run was step 1 (Import MI053001).
En datzelfde geldt voor de Eventlog:
SQL Server Scheduled Job 'Import MI053001' (0xC80A4008BD57484E82AFCBAEA5256C64) - Status: Failed - Invoked on: 2004-09-21 10:07:00 - Message: The job failed. The Job was invoked by Schedule 13 (Import MI053001). The last step to run was step 1 (Import MI053001).
Als ik de DTS-package zelf execute, dan is er niks aan de hand, en dus lijkt me dat er ergens in die scheduler iets niet goed gaat, maar wat dat zou kunnen zijn?

Iemand die hier een helder idee over heeft? :)

  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Rechten van de SQL Server agent op de betreffende FoxPro file? Als je hem runt via de agent kan de job in een andere security context uitgevoerd worden.

Oops! Google Chrome could not find www.rijks%20museum.nl


  • Pelle
  • Registratie: Januari 2001
  • Laatst online: 16:31

Pelle

🚴‍♂️

Topicstarter
En hoe check ik dat? Is de SQL Server Agent een lokale user oid? Bij een snelle check kwam ik geen specifieke SQL S.A. user tegen...

  • P_de_B
  • Registratie: Juli 2003
  • Niet online
In Enterprise Manager kun je onder de management node rechtsklikken op "SQL Server agent" en dan kiezen voor properties. Je kunt dan op het "General" tabblad het account specificeren waaronder de service draait. Dit account moet ook rechten hebben op de FoxPro file.

Oops! Google Chrome could not find www.rijks%20museum.nl


  • Pelle
  • Registratie: Januari 2001
  • Laatst online: 16:31

Pelle

🚴‍♂️

Topicstarter
Hmm, ook dit werkt niet.

Ik laat de SQL Server Agent nu onder een domain-admin user draaien (die ook admin is op die lokale SQL machine). Tevens heb ik de job-owner van de betreffende job op diezelfde user gezet, en tenslotte heb ik bij de eigenschappen van die FoxPro-file nog specifiek die user genoemd. Hierna de SQL Server Agent gerestart, maar ook dat maakt niets uit.

* Pelle snapt het niet meer 8)7

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 12-05 22:23

curry684

left part of the evil twins

Even een stukje 'ik had dit probleem vorige week ook vrijwel identiek' en het zat geloof ik zo: als je een DTS package start vanuit Enterprise Manager, draait ie onder de account van degene die 'm uitvoert. Als ie gescheduled is draait ie onder de account van de package owner as displayed in de Local Package list. Check dus dat die account afdoende rechten heeft!

Professionele website nodig?


  • Pelle
  • Registratie: Januari 2001
  • Laatst online: 16:31

Pelle

🚴‍♂️

Topicstarter
Die account mag alles op die bak, hij zit in de administrator groep...

  • Pelle
  • Registratie: Januari 2001
  • Laatst online: 16:31

Pelle

🚴‍♂️

Topicstarter
Heb nog even zitten klooien, maar ik wordt er geen wijs uit.
Weet iemand of er uitgebreidere log-tooltjes beschikbaar zijn om te checken wat er nou precies fout gaat tijdens het uitvoeren van zo'n job? Want met wat er in de eventlog staat, en in de jobhistory ('the job failed') kan ik niet zo veel.

  • curry684
  • Registratie: Juni 2000
  • Laatst online: 12-05 22:23

curry684

left part of the evil twins

Sja ik kwam er dus zelf ook niet uit en heb een collega in moeten schakelen moet ik eerlijk bekennen :X Ik had idd hetzelfde probleem met te weinig logs e.d.

Tis dat het een Brit is die geen woord Nederlands kent anders had ik 'm wel even langs gestuurd :) Overigens was het ook voor hem (datawarehousing expert) een aardige pot nattevingerwerk voordat ie er na een paar uur uitkwam.

Het opvallende verschil dat wij dus merkten was dat het wel goed ging als we via Remote Desktop de job uitvoerden vanuit een localhost Enterprise Manager, en het vanaf mijn laptop waar ik onder mijn eigen account draaide de mist in ging.... wellicht dat je daar nog iets mee kunt :)

Professionele website nodig?

Pagina: 1