[ASP] createtextfile zeer groot bestand *

[Verwijderd]

Voor het aanmaken van een CSV-file van het artikelbestand op een internetserver wordt gebruik gemaakt van een stukje programma dat alleen werkt als er geen grote "ntext"-velden (sql-server) worden verwerkt. Ga ik het programma op een testsysteem plaatsen dan kan het alle ntext-velden aan, ongeacht de omvang en inhoud. Beide databases zijn gelijk.
Ik heb geen idee meer waar ik moet zoeken.
Ook het boek: active server pages 3.0 van wrox geeft geen oplossing.
Het bestand wordt wel aangemaakt en alle gegevens worden wel geplaatst. Het bestand is niet meer ingebruik (te benaderen via notepad). Alleen de opvolgende commando's worden niet meer uitgevoerd. Dit in tegenstelling tot de test-server.

In onderstaand stukje komt het programma niet toe aan de response.write.

Zelf zit ik te denken over eea of andere instelling op de server.
Wij maken gebruikt van win2k-server. Op de internetserver is 3Gb werkgeheugen aanwezig. Het werkgeheugen loop niet vol.

Heeft iemand een idee waar ik moet zoeken??

------ programma voorbeeld -------

set ra = tfa.createtextfile(artpath,true,false)
qlstr = "select * from eco_artikel where parent is null order by sortnr, naam"
rs.open sqlstr,conn,1,3
do until rs.eof
ra.writeline verwerkregel
rs.movenext
loop
response.write "einde csv"
response.end
rs.close
ra.close

[RobIII]

Als je code post, gebruik dan code tags Kijk ook eens naar Debuggen: Hoe doe ik dat?

Wat is 'verwerkregel'? Is dat een variabele? Een functie? Krijg je een foutmelding?

Overigens worden de .close methods niet uitgevoerd omdat na response.end de verwerking van het script stopt.

offtopic:
En een kleine titlefix: [APS] > [ASP]

[ Voor 73% gewijzigd door RobIII op 20-06-2007 12:17 ]

[Verwijderd]

verwerkregel is een function die wordt aangeroepen en die de juiste gegevens retourneert om afgedrukt te worden. Deze function roept op zij beurd nog andere functions aan. Deze werken allemaal correct zolang er maar geen grote velden worden gebruikt.

Dat van de close is correct. Ik schrijf ook dat de response.write niet eens wordt uitgevoerd. Op de test-server werkt alles correct.

Er komt geen foutmelding, anders was het een stuk eenvoudiger.

[ Voor 7% gewijzigd door Verwijderd op 20-06-2007 12:30 ]

[RobIII]

En je weet zeker dat het op de test-omgeving met dezelfde orde-van-grootte velden wordt getest? Want het klinkt mij in de oren alsof de testomgeving dan toch minder (of "kleinere") inhoud bevat. Of misschien heeft het te maken met NULLs in je data, dat soort zaken. Je zult toch even wat moeten debuggen om uberhaupt al eens te kijken hoevaak (en of) verwerkdata wordt aangeroepen. Dan kun je al makkelijker analyseren waar het probleem zit. Zie daarvoor ook Debuggen: Hoe doe ik dat?

[ Voor 11% gewijzigd door RobIII op 20-06-2007 12:38 ]

[JJvG]

Aangezien de code en de database-inhoud niet verschillen, denk ik ook niet dat je het daarin moet zoeken. Ik denk dat je het eerder moet zoeken in je MDAC versie (2.0, 2.5 of 2.6) of in je ODBC-drivers. Probeer te zoeken naar andere verschillen tussen de systemen (andere useraccounts, andere rechten, verschillen in servicepacks) etc...

[Verwijderd]

JJvG.

Ik ga aan het werk met je adviesen. Kan wel even duren, moet ook nog andere zaken regelen.

[Verwijderd]

Ik heb eea getest. Alle met sp4. Ook de sql-server is hetzelfde.

Verder heb ik het volgende deel in het progje gewijzigd.
Het gehelen werken in hetzelfde gebleven, allen de zeer lange velden die geplaatst worden in de csv-file heb ik vervangen door een harde tekst ("test"). Alles werkt normaal. De progje komt nu correct bij de melding response.write.

Ik heb al aangegeven dat als ik de orginele velden gebruik de csv-file wel correct wordt aangemaakt, alle gegevens staan erin. Alleen loop het prog niet verder.

[JJvG]

Enige dat ik zo gauw nog kan verzinnen is dat je response buffer vol loopt of dat er iets anders gelimiteerd is in de productie-omgeving (ben je op je testomgeving Administrator? waarschijnlijk wel)
misschien moet je even zoeken op metabase.xml om in IIS te kijken wat de grenzen zijn van het wegschrijven of je response buffer. Standaard is je response.buffer enkele MB's. Vermoed dat je het dus in IIS moet zoeken.

[Verwijderd]

Waar moet ik zoeken voor de informatie over de buffers van iis. Ik gebruik iis 5.0.
Ondertussen heb ik als eerste regel in mijn prog "response.buffer = false" opgenomen. Ook geen resultaat.

Ik weet nu wel bijna zeker dat het aan de writeln zal liggen. Is binnen asp 3.0 er een limiet aan de regellengte???

[RobIII]

Verwijderd schreef op woensdag 20 juni 2007 @ 16:52:
Waar moet ik zoeken voor de informatie over de buffers van iis. Ik gebruik iis 5.0.
Ondertussen heb ik als eerste regel in mijn prog "response.buffer = false" opgenomen. Ook geen resultaat.

Ik weet nu wel bijna zeker dat het aan de writeln zal liggen. Is binnen asp 3.0 er een limiet aan de regellengte???

Waarom debug je je code niet door wat output te genereren in de lus? Dan weet je hoe vaak de lus aangeroepen wordt. Maak er eens iets van als volgt:

Visual Basic:

response.buffer = false
response.write "Begin verwerken<br>"

set ra = tfa.createtextfile(artpath,true,false)
qlstr = "select * from eco_artikel where parent is null order by sortnr, naam"
rs.open sqlstr,conn,1,3

response.write "Begin lus<br>"
do until rs.eof
  response.write "Verwerkregel<br>"
  ra.writeline verwerkregel
  rs.movenext
loop

response.write "einde csv"
rs.close
ra.close
response.end

Dan zie je in ieder geval al meer dan je nu doet. Probeer daarna in "verwerkregel" dezelfde methode toe te passen van debuggen.

[ Voor 3% gewijzigd door RobIII op 20-06-2007 17:02 ]

[bigbeng]

Verwijderd schreef op woensdag 20 juni 2007 @ 13:34:
Ik heb eea getest. Alle met sp4. Ook de sql-server is hetzelfde.

Verder heb ik het volgende deel in het progje gewijzigd.
Het gehelen werken in hetzelfde gebleven, allen de zeer lange velden die geplaatst worden in de csv-file heb ik vervangen door een harde tekst ("test"). Alles werkt normaal. De progje komt nu correct bij de melding response.write.

Ik heb al aangegeven dat als ik de orginele velden gebruik de csv-file wel correct wordt aangemaakt, alle gegevens staan erin. Alleen loop het prog niet verder.

Ik mis hier het antwoord op de MDAC vraag van JJvG. Dit is vrij essentieel, omdat MDAC niet altijd even goed om kon gaan met BLOB, TEXT en NTEXT. Daarover zijn ook diverse artikelen te vinden op het internet.
Een generieke oplossing die toen (lang lang geleden, sprak bigbeng) werkte, was het uitschrijven van je query (dus niet select *, maar select veld1, veld2 etc...) en ervoor zorgen dat de ntext velden achteraan in de query staan en dat je ze ook in die volgorde steeds uitleest uit de recordset.

[Verwijderd]

Het prgramma is technisch goed, want het werkt wel op de test-server. Ook het debuggen op de werkserver heeft geen zin omdat alle records correct worden verwerkt en in de textfile worden geplaatst.
Alle velden uit de database worden correct verwerkt.
Laat ik alles in het programma hetzelfde, zelfde afhandeling van de velden en records, maar schrijf ipv de text uit het record alleen een textstring dan werkt het goed.
Schijf ik alleen de eerste 2 posities van de textvelden, mbv left(veld,2), dan komt het programma wel correct tot een einde.

Ik blijf erbij dat het probleem zich voordoet in de lengte van de te schrijven regel met writeline.
Zijn hieraan beperkingen per systeem in te stellen? Zoja waar kan ik die vinden? (ben geen systeembeheerder)

[Verwijderd]

Ik heb met het versienummers van de MDAC nagekeken: op de testserver draait 2.60 en op de productieserver 2.81.

[bigbeng]

Okee, ik begin de draad een beetje kwijt te raken.

Het bestand wordt dus onder alle omstandigheden goed gemaakt? Of stopt hij bij een bepaald record? Overigens is notepad op het bestand loslaten geen goede test om te bepalen of het bestand nog in gebruik is, omdat een bestand meestal alleen voor schrijven gelocked wordt. WordPad geeft wel een melding of een bestand in gebruik is.

Ik zou toch RobIII's suggestie volgen en even wat debugstatements opnemen in je code. Je kunt bijvoorbeeld een logbestand naast je normale bestand openen en daar de regels naartoe schrijven (ipv naar de Response).
Ik ben er vrij zeker van dat dit een ADO probleem is, vooral gesteund door opmerkingen als:

Verwijderd schreef op woensdag 20 juni 2007 @ 13:34:
...
Het gehelen werken in hetzelfde gebleven, allen de zeer lange velden die geplaatst worden in de csv-file heb ik vervangen door een harde tekst ("test"). Alles werkt normaal.
...

Wat ik weet van de ADO NTEXT problemen is dat hij raar gedrag gaat vertonen, en dus niet noodzakelijk met foutmeldingen komt, maar gewoon vastloopt.

[JJvG]

Ik heb ook behoorlijk lopen googlen naar soortelijke meldingen, maar echt veel kon ik er niet over vinden. Ik denk dat het nog te maken kan hebben met je response buffer; mogelijk mag je pagina niet meer dan 1 of 2 MB gebruiken tijdens het verwerken en klapt-ie er daarom bij grote teksten uit. Kun je het achterhalen wat de lengte is van de waarde in de kolom en die er bij printen? Je kunt dan makkelijker achterhalen op welk moment (bij welke lengte) het fout gaat.

Iets als

Visual Basic:

response.write Len(rs.Field(Veldnaam)) & " - " & rs.Field(Veldnaam)

Ik heb wel iets gevonden over 1024 karakters en ik heb zelf ook wel eens iets opgehakt in kleine chunks om het goed te kunnen streamen. Misschien dat dit je nog meer informatie geeft.

Visual Basic:

while (!(streamObj.EOS)){
    Response.BinaryWrite(streamObj.Read(4096));
}

Bron: http://www.programmershea...ReadMessage.aspx?S=B20000

[ Voor 12% gewijzigd door JJvG op 21-06-2007 16:44 . Reden: voorbeeld code toegevoegd voor response in chuncks ]

[bigbeng]

JJvG schreef op donderdag 21 juni 2007 @ 16:40:
Ik heb ook behoorlijk lopen googlen naar soortelijke meldingen, maar echt veel kon ik er niet over vinden. Ik denk dat het nog te maken kan hebben met je response buffer; mogelijk mag je pagina niet meer dan 1 of 2 MB gebruiken tijdens het verwerken en klapt-ie er daarom bij grote teksten uit.
...

Als ik naar de voorbeeldcode van de TS kijk, dan schrijft hij de data helemaal niet naar de response en heeft het dus ook niets met de buffergrootte te maken. Volgens mij zit jij op een ander spoor

[ Voor 34% gewijzigd door bigbeng op 21-06-2007 17:50 ]