Toon posts:

[ASP] Server gaat hangen na deze code *

Pagina: 1
Acties:

Verwijderd

Topicstarter
Beste mensen.. Ik heb een probleem..

Ik heb een poll die de vragen en antwoorden uit een database haalt...
Nu heb ik dus een admin pagina gebouwd. zodat je via een website de vragen en antwoorden kan veranderen.....

Deze code is:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<%
dim cnn,rst
set cnn = Server.CreateObject("ADODB.Connection")
set rst = Server.CreateObject("ADODB.RecordSet")
cnn.Open("Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath("weekly_poll.mdb"))
sqltext = "Select * FROM tblPolls"
rst.Open sqltext,cnn,3,3


dim vraag, antwoord1, antwoord2, antwoord3,antwoord4,aantal
vraag = Request.Form("vraag")
antwoord1 = Request.Form("antwoord1")
antwoord2 = Request.Form("antwoord2")
antwoord3 = Request.Form("antwoord3")
antwoord4 = Request.Form("antwoord4")
aantal = Request.Form("aantal")





rst.AddNew
rst("Question") = vraag
rst("Selection_1") = antwoord1
rst("Selection_2") = antwoord2
rst("Selection_3") = antwoord3
rst("Selection_4") = antwoord4

rst.update


set fso = createobject("scripting.filesystemobject")
set act = fso.opentextfile(server.mappath("aantal.txt"))
if aantal = 2 then
Set act = fso.CreateTextFile(server.mappath("aantal.txt"), true)
act.WriteLine("180")
Else IF aantal = 3 then
Set act = fso.CreateTextFile(server.mappath("aantal.txt"), true)
act.WriteLine("230")
Else
Set act = fso.CreateTextFile(server.mappath("aantal.txt"), true)
act.WriteLine("270")


End IF
End IF 


Response.Redirect "adminweekly_poll.asp"

%>



Nou werkt die poll gebeuren foutloos..
Maar als ik mijn lijstje met vragen en antwoorden invul en ik druk op toevoegen (dan gaat ie dus naar deze code) gaat de server hangen... dan kan ik er een hele poos niet meer bij.

Het laadbalkje onder in IE gaat ook heel langzaam...

Als ik na een kwartier er weer bij kan zijn alle weizigingen toch wel in de database beland... en het goede getal komt ook in aantal.txt...

Dus het werkt wel... Maar waarom hangt mijn server een kwartier ?

Please Help...

[ Voor 12% gewijzigd door Verwijderd op 21-10-2004 02:04 ]


Verwijderd

Hoe wordt deze code aangeroepen? Is dit een procedure ofzo? Wordt die toevallig meer dan 1 keer aangeroepen? Hoe groot is tblPolls?

En waarom doe je set act = fso.opentextfile(server.mappath("aantal.txt")) als je hem daarna gaat overschrijven?

  • alx
  • Registratie: Maart 2002
  • Niet online

alx

heb zelf nooit serieus naar Vis Basic (.Net) gekeken (of is dit geen VB?), maar los daarvan zou ik rondom enkele statements de tijd naar een bestandje laten schrijven,
zodat je weet welk deel er zo lang duurt.
Dus bv rond statements als regel 3-5, regel 6, regel 10-16, 22-29, 33-42.
En dan evt voor een 2e keer enkele regels isoleren mocht de grote tijdssink nog niet
duidelijk zijn.
Dan weet je in ieder geval wat er 15 min duurt (en of dat inderdaad in dit stuk code
zit). Post dan je resultaat, wellicht dat iemand die deze taal en de exacte
eigenschappen van de gebruikte functies wel kent het weet.

Verwijderd

@simulacrum: di's ASP met als taal VBScript, zie http://msdn.microsoft.com...56/html/vtoriVBScript.asp

Verwijderd

wat je in ieder geval niet doet is netjes alles weer afsluiten:
ASP:
1
2
3
4
rst.close
cnn.close
set rst=nothing
set cnn=nothing

Dat is nou niet direct het antwoord op je probleem, maar het blijft wel erg belangrijk

  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Heb je toevallig Norton Antivirus op de Server? Deze kan niet samenwerken met het Scripting.FileSystemobject.

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


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 13:21

gorgi_19

Kruimeltjes zijn weer op :9

FSO mag trouwens ook wel eens expliciet gesloten worden. En gebruik Server.CreateObject ipv CreateObject

Zie trouwens ook P&W FAQ - ASP ; dit is mede een kwestie van debuggen. Je code uitkleden totdat je weet waar het fout gaat; welk stukje van de code de oorzaak is. Gooi tussendoor eens de tijd tussendoor; weet je welke procedure het langste duurt.

Op het eerste gezicht lijkt het er enorm op dat je resources gebruikt, niet vrijgeeft en daardoor moet wachten tot de resources time-outen (en dat kan lang duren)

Daarnaast [ASP] in de titel gefrot

[ Voor 71% gewijzigd door gorgi_19 op 21-10-2004 08:59 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


  • j_du_pee
  • Registratie: Maart 2000
  • Laatst online: 23-09-2024

j_du_pee

du pain, du vin, du pee

Je doet aan het eind van je script ook een redirect. Is deze redirect niet toevallig naar dezelfde pagina, of een andere pagina die ook weer redirect :?
Bij een hangende server kijk ik iig altijd eerst naar de mogelijkheid van infinite loops in mijn scripts...

kaart != map && bottel != fles
Wacht op antwoord


  • KurtDB
  • Registratie: Juni 2004
  • Laatst online: 13-05 09:19
1. Zoals eerder gezegd: alle openstaande connecties (naar db of files) altijd expleciet afsluiten.
2. Een "SELECT *" is al niet positief voor de performantie. Gelieve dus de veldnamen aan te geven.
3. Gebruik in ASP de functie getrows om de resultaten van je query in 'n array te krijgen. Hierna kan je je connectie afsluiten, waardoor er weer minder system resources verspeeld worden.
4. Gelieve al je variablen te declareren. (alhoewel dit niet verplicht is in asp, maar ik zie bv een sqltext die niet gedeclareerd wordt)
5. Je gaat inderdaad eerst een txt-file openen en daarna ga je die txt-file ook aanmaken. De logica die daarachter zit ontgaat me echter compleet.
6. Gelieve ook met queries te werken ipv met die rst.Addnew. Een query kan je ten allen tijde gaan debuggen, terwijl je met die addnew eigenlijk niets kan aanpassen. (ik vind 't sowieso een vieze manier van scripten)

  • abeker
  • Registratie: Mei 2002
  • Laatst online: 12:33

abeker

...

KurtDB schreef op 21 oktober 2004 @ 11:03:
6. Gelieve ook met queries te werken ipv met die rst.Addnew. Een query kan je ten allen tijde gaan debuggen, terwijl je met die addnew eigenlijk niets kan aanpassen. (ik vind 't sowieso een vieze manier van scripten)
Vieze manier van scripten.. mwa smaken verschillen blijkbaar :P

Deze methode van toevoegen van records heeft wel als voordeel dat je na de de toevoeging meteen de identifier van de nieuwe record weet (indien aanwezig uiteraard). Ook voorkom je door deze methode te gebruiken gratis SQL injection, scheelt dus weer code om je data te escapen.

Je punt over debuggen zie ik niet echt.

Oh ja, die SELECT query kan natuurlijk beter door nooit records op halen, want je wilt eigenlijk alleen de structuur van de tabel weten. Als iemand een nog betere methode weet om die structuur te achterhalen, hoor ik het trouwens graag! (ja je kunt natuurlijk ook zelf fields toevoegen, maar dat is minder generiek en slechter onderhoudbaar)

terug naar de code. Alle objecten die je aanmaakt moet je natuurlijk ook weer netjes afbreken, zoals eerder al aangegeven was. Dus ook je files netjes afsluiten. Die redirect zou ook problemen kunnen opleveren als daardoor oneindig veel redirects onstaan. In dat geval merk je dat wel in FireFox, die geeft na een tijdje de foutmelding 'Redirection limit exceeded'.

[ Voor 16% gewijzigd door abeker op 21-10-2004 11:46 ]

the less one forgets, the less one remembers


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
abeker schreef op 21 oktober 2004 @ 11:41:
[...]

Vieze manier van scripten.. mwa smaken verschillen blijkbaar :P

Deze methode van toevoegen van records heeft wel als voordeel dat je na de de toevoeging meteen de identifier van de nieuwe record weet (indien aanwezig uiteraard). Ook voorkom je door deze methode te gebruiken gratis SQL injection, scheelt dus weer code om je data te escapen.
Een insert query is sneller, heeft als je het goed doet geen risico op SQL injection, en je kunt net zo goed ook de nieuwe identity weten. Ik zou echt met SQL queries gaan werken en niet met recordsets.

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


  • haroldd
  • Registratie: April 2004
  • Laatst online: 22-03 21:11
P_de_B schreef op 22 oktober 2004 @ 07:26:
[...]


Een insert query is sneller, heeft als je het goed doet geen risico op SQL injection, en je kunt net zo goed ook de nieuwe identity weten. Ik zou echt met SQL queries gaan werken en niet met recordsets.
wat is door jou de aanbevolen methode om na insert query de nieuwe identity te achterhalen?

Werken is gezond, laat het daarom over aan de zieken!


  • TeeDee
  • Registratie: Februari 2001
  • Laatst online: 10:37

TeeDee

CQB 241

code:
1
select @@identity as blaat from dbo.tabel

zou moeten werken.

Heart..pumps blood.Has nothing to do with emotion! Bored


  • wizzkizz
  • Registratie: April 2003
  • Laatst online: 19-12-2025

wizzkizz

smile...tomorrow will be worse

haroldd schreef op 22 oktober 2004 @ 12:04:
[...]


wat is door jou de aanbevolen methode om na insert query de nieuwe identity te achterhalen?
SELECT @@IDENTITY FROM TABLE (Access en SQL-Server)

SELECT LAST_INSERT_ID() FROM TABLE (mySQL)

edit:

TeeDee was nét iets sneller :(

edit:

je kunt het AS-statement gebruiken om er een naampje aan te geven. je kunt het ook ophalen met rso(0)

[ Voor 23% gewijzigd door wizzkizz op 22-10-2004 12:17 ]

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.


  • mulder
  • Registratie: Augustus 2001
  • Laatst online: 13:56

mulder

ik spuug op het trottoir

Voor SQL-Server is SCOPE_IDENTITY() te prefereren

oogjes open, snaveltjes dicht


  • haroldd
  • Registratie: April 2004
  • Laatst online: 22-03 21:11
ok bedankt, ik ga het proberen :)

Werken is gezond, laat het daarom over aan de zieken!


  • abeker
  • Registratie: Mei 2002
  • Laatst online: 12:33

abeker

...

Gokje: Bad_Beaver gebruikt een Access database, dus de genoemde methoden om de identity op te halen werken niet.

Een insert query is idd sneller dan deze methode, maar het zou best kunnen zijn dat door de extra werk die je moet verrichten (escapen van velden) een query langzamer is. Dat is zeker iets dat ik nog ga testen.

the less one forgets, the less one remembers


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
abeker schreef op 22 oktober 2004 @ 13:16:
Gokje: Bad_Beaver gebruikt een Access database, dus de genoemde methoden om de identity op te halen werken niet.
Jawel hoor, Access2000 ondersteunt @@identity.

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


  • gorgi_19
  • Registratie: Mei 2002
  • Laatst online: 13:21

gorgi_19

Kruimeltjes zijn weer op :9

Een insert query is idd sneller dan deze methode, maar het zou best kunnen zijn dat door de extra werk die je moet verrichten (escapen van velden) een query langzamer is.
Ook parametrized queries werken in MS Access; je hoeft dan niet eens te escapen. :) Geen idee alleen of MS Access ook het execution plan cached.

[ Voor 11% gewijzigd door gorgi_19 op 22-10-2004 19:02 ]

Digitaal onderwijsmateriaal, leermateriaal voor hbo


  • abeker
  • Registratie: Mei 2002
  • Laatst online: 12:33

abeker

...

aha, ik dacht dat @@identity alleen werkte in MSSQL :)

Ik heb het een en ander getest, het gebruiken van een insert query is een factor 3 sneller dan een addnew op een recordset. Zodra je ook de identity wilt ophalen, is het gebruik van queries bijna 2x zo snel. Een 'gewone' query is ongeveer even snel als een parametrized query.

Gelukkig is de snelheid van insert-queries niet van belang bij het project waar ik nu aan werk :)

the less one forgets, the less one remembers


Verwijderd

Wat ik niet begrijp in je code waarom je een textfile naast je database gebruikt...?

Waarom niet een iets ander datamodel waarin je ook het aantal stemmen opslaat?

Volgens mij ben je dan al van je snelheidsproblemen af.
Pagina: 1