Flyttade över en del kod från en stationär till en bärbar utan nätverksanslutning.

När jag där försöker mig på att köra ASP-kod mot Accessdatabas
så fungerar det utmärkt så länge jag inte försöker skapa nya
poster, uppdatera eller ta bort poster. Att visa poster som vanligt
fungerar som det skall.

Följande felmeddelande uppträder vid försök att skapa poster m.m.

-------------
Feltyp:
Microsoft JET Database Engine (0x80004005)
Operationen måste använda en fråga som kan uppdateras.
-------------

Koden har testats på andra maskiner och fungerar där utan fel.
Så felet måste ligga nånstans i inställningarna i
IIS 5, Access eller vad vet jag.

I övrigt går det utmärkt att köra ASP-applikationer så IIS verkar vara sjyst installerad.

Nån som har nåt tips eller idé?

mvh
Torbjörn

Om du söker i forumet på detta felmeddelande kommer du märka att det är en av de vanligaste frågorna. Felet beror på att användaren IUSR_datornamn inte har skrivrättigheter på databasfilen.

/Johan

Ok tackar!

misstänkte nästan att det var ett rättighetsproblem.

använder WinXP Pro som jag inte är helt van vid och försöker hitta nånstans att åtgärda detta..

Antar att någon har lite tips om var man går in...?

mvh
Torbjörn

JohanD:

Följdfråga.

Är du helt säker på att det är så?

Jag hade samma problem ute hos en kund och jag testade att konvertera DB:n från Access 2000 till Access 97.

Därefter fungerade det...

Fattade aldrig vad felet var den gången...

borde vara det, då det testats på annan maskin med samma programvara.. XP och Access 2002.

Vet att jag tidigare hade rättighetsbekymmer med SQL server som rättades till via IUSR. Detta var dock i Win2000 och det ser lite annorlunda ut mot XP. Jag har därmed kört fast när det gäller dessa inställningar i XP.

Lösningen finns nånstans i närheten.... det känner jag :)

/Torbjörn

Torbjörn:
Jag kör inte XP själv, men det borde gå till så att man högerklickar på filen och väljer egenskaper. Där borde det finnas inställning för behörigheter. Hoppas någon som kör XP kan bekräfta eller komma med den rätta lösningen.

fredda:
Man kan ju aldrig vara säker när det gäller datorer och man ska aldrig vara säker på att det är på ett visst sätt ;) Givetvis kan felet bero på något annat, men eftersom det är ett väldigt klassiskt fel att inte sätta rätt rättigheter på filen gissade på det när scriptet fungerade i en annan dator. Ang. ditt fel, du använde inte för gamla drivrutiner? Bara en gissning, men drivrutinerna till Access97 kanske bara klarar av att läsa i en Access 2000-databas? Som sagt, bara en vild gissning från mig...

/Johan

Kikade på både katalog och filrättigheter och har avmarkerat skrivskyddet för hela wwwroot samt aktuella filer. Samma sak... så om man på något sätt hitta liknande inställningar under IIS eller liknande så kan det nog lösa sig..tror jag?

Kör man win2000 så grejade man rättigheterna direkt via användarkontot men här verkar det vara annorlunda..

Torbjörn

Problemet löst...

Gick under:
inställningar/kontrollpanelen/administrationsverktyg/datorhantering

tilldelade konton administratörsrättigheter och sedan skapade jag
lösenord för adminkontot, vilket jag inte tyckte var nödvändigt först.

Antar att detta lösenord är avgörande av någon anledning. Tyvärr blir det lite tjatigt att logga in varje gång man slår på burken..

Men tack för alla ledtrådar...

trevlig midsommar på er :)

/Torbjörn

>tilldelade konton administratörsrättigheter och sedan skapade jag
>lösenord för adminkontot, vilket jag inte tyckte var nödvändigt först.

Menar du att du har gett adminrättigheter till IUSR-kontot? I sådana fall bör du genast ta bort dessa! Det innebär att ett script kan göra vad som helst med datorn... Om nu detta löste problemet beror ju grundproblemet på att rättigheterna är fel, då får du fortsätta leta där.

/Johan

Hej igen

JohanD:

Nej jag hade inte äldre drivrutiner. MDAC 2.6 och Jet 4.0.
Det var säkert rättigheter som var mitt problem med...

Jag tackar. En grej till att lägga till kuskapshyllan.

Trevlig midsommar.

IUSR är nu bortkopplad från adminrätten.....

Det fungerar ändå.. så länge man loggar in med lösenord.
Så det har utan tvekan ett samband med inloggningen och
att det "ploppar" fram särskilda rättigheter i och med detta. Dessutom visas några extra ikoner som inte visas annars...

Skumt värre och skummare blir det...

Jag upptäckte dessutom att det inte går att köra
FSO på en exakt likadant konfigurerad XP-maskin oavsett om
man loggar in eller ej. Mycket troligt ligger det liknande problem
bakom detta. å jodå komponenten finns där och är registrerad :)

Om det är någon som känner sig någorlunda hemma i WinXP Pro
och dess användarkonton med rättigheter så skriv gärna ett par
rader här.

mvh
Torbjörn

>Jag upptäckte dessutom att det inte går att köra
>FSO på en exakt likadant konfigurerad XP-maskin oavsett om
>man loggar in eller ej. Mycket troligt ligger det liknande problem
>bakom detta. å jodå komponenten finns där och är registrerad :)

Det har tidigare diskuterats om att vissa antivirus-program blockerar FSO, det kan inte vara något sådant?

/Johan

Jäpp där hade vi lösningen.....

inaktiverade scriptkontrollen i Norton.

/Torbjörn