[2000] Useraccount van 2-de laags applicatie*

[OZ-Gump]

De search hier, evenals die op Google groups en MSDN hebben me helaas nog geen antwoord kunnen geven. Vandaar mijn post hier. Eerst even wat achtergrondinformatie:

- Windows 2000 server
- Zelf geschreven applicatie die Access start voor onderhoud op database
- Werkt allemaal naar behoren

Nu zul je denken: als het naar behoren werkt, waarom post je hier dan? Nou, dat zal ik je melden...

De zelfgeschreven applicatie (welke dus een aantal malen onderhoud uitvoert op een Access database, zoals het onvermijdelijke compact & repair, maar ook een zogenaamd 'nachtprocedure') werkt correct wanneer deze met de hand gestart wordt. Wanneer de Windows scheduler gebruikt wordt, loopt het zaakje echter vast in een van de Access-acties. We hebben de zogenaamde 'nachtprocedure' al helemaal leeggegooid, maar zelfs dan blijft de Access taak hangen en sluit dus niet af.

De vraag
Wanneer een applicatie gestart wordt door middel van een scheduler, kun je daarin logingegevens meegeven waarmee de applicatie gestart wordt. Wat gebeurt er met applicaties die door de geschedulede applicatie gestart worden? Worden deze gestart met hetzelfde useraccount als waarmee de geschedulede taak gestart wordt, of wordt die gestart met bijvoorbeeld het gelimiteerde System account? Het lijkt namelijk alsof Access niet voldoende rechten heeft om de zaken af te handelen. Is er iemand in huis die hier een antwoord op weet?

Achtergrond info
De applicatie draait bij een klant, en de klant is niet zeer flexibel in het plaatsen van testapplicaties en debugversies. Hierdoor is de mogelijkheid tot het debuggen op locatie beperkt.

[Verwijderd]

de taskscheduler voert taken uit met het gespecificeerde account.

heb je userenv foutmeldingen (failed to unload userprofile ...)

[Semt-x]

helaas kan ik je geen kant en klare oplossing bieden, alleen wat handvaten om deze situatie te verklaren en oz een oplossing te bedenken.
- Zoek uit in hoeverre rechten op tabellen in een access database worden ondersteund. (het domein account dat je in die schduled task selecteert heeft mogelijk geen rechten om in die database te komen, laat staan tabellen te lezen)
- mogelijkheid is MSDE of MSSQL gebruiken, dan zie ik wel de oplossing.

[OZ-Gump]

@iis5_rulez:
userenv foutmeldingen ga ik meteen navragen bij de klant: zal vragen om de eventlogs eens na te zoeken en eventueel door te mailen.

@Semt-x_:
MSDE of (MS)SQL is helaas geen optie. Het betreft hier een enorm uitgebreide applicatie welke slechts gedeeltelijk door ons ontwikkeld is. Wanneer we de app. proberen te upscalen naar SQL Server krijgen we veel fouten. Eén daarvan is dat er teveel open verbindingen zijn in verband met de grote hoeveelheid aan gegevens op de schermen.

We hebben de onderhoudsapplicatie wel geschreven, waarmee we dus nu een probleem hebben. In de toekomst wordt de Access applicatie waarschijnlijk wel ooit herschreven, maar dat is voorlopig nog niet aan de orde. Tot die tijd dient deze applicatie werkend gemaakt te worden.

Het is geen probleem van rechten op de tabellen, maar eerder bijvoorbeeld netwerkresources of file-access. Binnen de Access applicatie zijn de rechten door onszelf gerealiseerd, dus daar zullen we waarschijnlijk geen problemen mee hebben.

[ Voor 14% gewijzigd door OZ-Gump op 06-12-2004 16:42 ]

[elevator]

Is het misschien zo dat de console gelocked is op het moment dat die scheduled task uitgevoerd wordt?

Anders gezegd - heb je het probleem ook als je inlogged met dezelfde account als de taak gescheduled is, en vervolgens met 'Run' de job handmatig start?

Ik heb een situatie gehad op 2003 waarbij een specifieke scheduled task niet goed liep tenzij de ingelogde user ook de user was waaronder die scheduled task liep

[OZ-Gump]

Is het misschien zo dat de console gelocked is op het moment dat die scheduled task uitgevoerd wordt?

That's a yes. De systeembeheerder wil pertinent niet dat de server continu aangemeld staat. De server is dus in ieder geval gelocked, maar misschien zelfs niet eens aangemeld.

Anders gezegd - heb je het probleem ook als je inlogged met dezelfde account als de taak gescheduled is, en vervolgens met 'Run' de job handmatig start?

Dat kan ik de goede man nog eens vragen. Die vraag gaat mee in de mail waarin ik om de eventlogs vraag...

[elevator]

Het is voor jou geen mogelijkheid om 'even' (?) de situatie van de klant na te bootsen om op die manier zelf e.e.a. aan troubleshooting te proberen?

[OZ-Gump]

elevator schreef op maandag 06 december 2004 @ 17:09:
Het is voor jou geen mogelijkheid om 'even' (?) de situatie van de klant na te bootsen om op die manier zelf e.e.a. aan troubleshooting te proberen?

In principe wel. Vervelende is alleen dat het niet makkelijk is om aan onze 'opdrachtgever' samen met wie de software gemaakt is, uit te leggen dat die kosten gefactureerd gaan worden. Toch ga ik waarschijnlijk even een virtual peeceetje inrichten om een en ander te testen...

[Remco]

Als het goed is, kan je een applicatie starten onder een andere usernaam met een commandline.
Schedule gewoon een batch, en laat deze batch de applicatie starten met de commandline.

Even gegoogled voor je:

http://support.microsoft.com/?kbid=225035

ps.
Je had wel gezocht ???? zoals vermeld in ts

[ Voor 27% gewijzigd door Remco op 06-12-2004 17:25 ]

[Verwijderd]

elevator schreef op maandag 06 december 2004 @ 16:55:
Is het misschien zo dat de console gelocked is op het moment dat die scheduled task uitgevoerd wordt?

Anders gezegd - heb je het probleem ook als je inlogged met dezelfde account als de taak gescheduled is, en vervolgens met 'Run' de job handmatig start?

Ik heb een situatie gehad op 2003 waarbij een specifieke scheduled task niet goed liep tenzij de ingelogde user ook de user was waaronder die scheduled task liep

ik heb met ntbackup van 2k3 gemerkt, dat de schedule job in het profile van de gebruiker, die de job aanmaakt, wordt gezet. als je die backup job schedulede moest het schedule account dus rechten hebben op een ander profile. misschien hetzelfde probleem?

[ Voor 3% gewijzigd door Verwijderd op 07-12-2004 16:51 ]