12 svar · 394 visningar · startad av OveRRidE
Hej allihopa!
Hoppas er dag har varit bättre än min, för jag har slitit mitt hår på kontoret nu i nästan tre dagar i sträck över det här problemet och ironiskt nog har det med en uppladdningskomponent att göra. ;)
Jag har ett helt vanligt formulär som postar en bild till ett ASP-script som laddar upp bilden, samt sätter ett värde i databasen när den är klar. Scriptet fungerar hur bra som helst för mig på min utvecklingsserver, på företagets testserver samt på den skarpa servern för mig, men inte för kunden.
Jag testade t.o.m. att skriva en egen filuppladdningskomponent, eftersom jag inte litar på SoftArtisans FileUp, men det hjälpte föga.
Felmeddelandet jag får är nu:
[red]ComOne error '800a0005'
Invalid procedure call or argument
/ADMIN/uploadImage.asp, line 9 [/red]
på raden som anropar sub:en som laddar upp filen. Det måste ju ha med sökvägen att göra tänkte jag så jag skrev ut den, men den är helt korrekt, på både min maskin och kundens.
Koden ser ut som följande (röd rad är felmeddelanderaden):
response.buffer = true
fileName = request.querystring("id") & ".jpg"
filePath = Server.Mappath("../gfx/kampanj/")
file = filePath & "\" & fileName
Set ObjUpload = Server.CreateObject("ComOne.FileUp")
With ObjUpload
.filePath = file
[red].DoUpload[/red]
End with
Set ObjUpload = Nothing
set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("../data/data.mdb")
conn.execute("UPDATE kampanjer SET levbild = '" & fileName & "', isAktiv = 1 WHERE ID = " & request.querystring("id") & ""),,128
set conn = nothing
response.redirect "image.asp?id=" & request.querystring("id")
Kan det ha med någon spärr på klienten att göra eftersom det fungerar med mina maskiner med inte på deras? De har testat på två olika.
Hjälp! :D
Jag skulle nog räkna bort att det är fel i koden om det fungerar hos er på flera miljöer (men det beror ju helt på hur allt är uppbyggt). Kolla istället vad som är skillnaden mellen er och kunden: Rättigheter (komponenten, iusr o.s.v), sökvägar, version på IIS, ASP och VBScript et.c
Bena ut vad som är skillnaden, och börja därifrån. :)
Rättigheter på komponenten, sökvägar eller version på IIS spelar ju ingen roll, eftersom både jag och kunden kör mot samma server hela tiden.
Skillnaden måste ju ligga på klienten eller som @nders föreslog innan idag; i proxyn. Jag har däremot ingen erfarenhet av proxy:s och eventuella problem som den kan skapa, så jag kan inte lösa det tyvärr. Anledningen för att jag postade i ASP är för att jag hoppas att någon varit med om något liknande, om det kanske har med form:et att göra eller nåt.
Det verkar helt enkelt som deras proxy inte tillåter att en fil skickas på det sättet.
Har du själv skrivit "ComOne.FileUp"? I så fall kan du väl lägga in debugg/loggfunktioner i DoUpload-metoden. Om sen du och kunden skickar tex samma bild så kan du ju se vilka skillnader det blir.
Det verkar helt enkelt som deras proxy inte tillåter att en fil skickas på det sättet.
Fast då borde de väl vara medvetna om att de har problem med filuppladdningar via HTTP överhuvudtaget?
Jag har skrivit komponenten själv, ja. Jag vet inte riktigt vad jag skall logga för något bara.. :)
Fast då borde de väl vara medvetna om att de har problem med filuppladdningar via HTTP överhuvudtaget?
Jo, men hur mycket filluppladdningar via HTTP använder ett plockvaruhus egentligen på sina kontorsdatorer? ;)
Jag har skrivit komponenten själv, ja. Jag vet inte riktigt vad jag skall logga för något bara..
Du borde väl kunna se på exakt vilken rad det smäller om inte annat?
Jo, men hur mycket filluppladdningar via HTTP använder ett plockvaruhus egentligen på sina kontorsdatorer?
Vet ej. Men att konfigugera en proxy/brandvägg att inte tillåta uppladdning med filändelsen "jpg" låter ju lite hårt. Har du provat med filer med andra ändelser? Har du bett dem prova ladda upp filer på andra siter tex bilagor i Hotmail (om dom kan accessa den).
I vilket fall som helst så borde ju deras IT-ansvarige kunna svara på dessa frågor och lösa problemet. Om det ligger där ..
Du borde väl kunna se på exakt vilken rad det smäller om inte annat?
Eftersom komponenten är kompilerad när den testas av kunden, så ser man ju inte det. Man får ju bara ett felmeddelande från dll-en och vilken rad det handlar om i ASP-filen, inte vilken rad i komponenten. Som sagt, på min burk (när jag felsöker) funkar den ju alltid.
Hur får jag ut exakt vilken rad i komponenten som felet ligger på då? Går det att få fram genom err-samlingen?
I vilket fall som helst så borde ju deras IT-ansvarige kunna svara på dessa frågor och lösa problemet. Om det ligger där ..
Jag frågade vem som var ansvarig, men de har ingen som är det. Kunden sitter i stlhm och jag ungefär 30 mil därifrån så.. ;)
Hur får jag ut exakt vilken rad i komponenten som felet ligger på då? Går det att få fram genom err-samlingen?
Ja, om man numrerat sina rader så finns ju den odokumenterade featuren Erl.
Mer allmänt så kan du ju lägga in debuggloggningar på varje rad för att se exakt vad som händer och var det går fel.
Om du sen misstänker att det är proxyn som bråkar och klipper i din data så kanske Request.TotalBytes och resultatet från BinaryRead är intressant att jämföra i fallet när det funkar, och inte funkar.
Mer allmänt så kan du ju lägga in debuggloggningar på varje rad för att se exakt vad som händer och var det går fel.
Förslag?
Var hamnar debug utskrivningar från en komponent? I nån loggfil? Och hur skriver jag det smidigast?
Det absolut enklaste i detta fallet är väl att logga precis allt som händer, rad för rad, (klockslag, variabelvärden, IP) till en flat textfil. Open, Print .. Close.
Loggningsfunktionerna kan du sen slå av och på genom vilkorlig kompilering så att du slipper ha det med i den skarpa versionen.
Sen, som sagt, har kunden experimenterat provat med olika filtyper, olika filstorlekar, olika browsers osv ..? Uppstår felet alltid?
Browsern är högre version än vad jag har, samt att jag bad honom skicka över filen till mig som han försökte ladda upp. Det var en vanlig RGB-jpeg och när jag testade med denna bild fungerade det perfekt. :l
Det var en vanlig RGB-jpeg och när jag testade med denna bild fungerade det perfekt.
Ja, och då blir det ju intressant att ta reda på exakt vad som skiljer deras POSTning från din.
Nu vet jag inte hur din kod ser ut men all data från POSTen finns ju tillgänglig via Request-objektet inne i din kod och om du dumpar detta till disk så borde du kunna upptäcka skillnader.
Om skillnaderna är minimala så är det kanske något du borde kunna hantera i din kod. Om proxyn däremot tagit bort hela datan så är det ju inte mycket att göra från ditt håll.
Vet du förresten överhuvudtaget att dom använder en proxy?
Är filen stor? Funkar det med mindre filer?
Det verkar skumt om proxyn skulle blockera filuppladdning via http formulär. De flesta företag sitter ju bakom proxy som tillåter uppladdning via ftp.
