---

Hej Gruppe

Jeg har et problem med et program jeg har lavet i visual basic til Excel 97:
Det går ned som følge af out of memory. Og den går ikke bare ned, men ned
med et brag - computeren fryser, fejlmeddelelsen bliver ikke vist i en pæn
dialogboks, men derimod i den grimme hvide kasse og man skal afbryde på
powerknappen for at komme ud.

Programmet er opbygget som følger:
1 del. Åbner en fil, laver en masse forskellige operationer på regnearket
(den tungeste del)
2 frl. Retter lidt i opsætning, skriver filen ud, lukker den, og åbner den
næste.. OSV.

Det er altid i del 1 programmet går ned. En del af problemet er at
programmet aldrig går ned samme sted. Det skal altid have kørt mindst 3-4
filer før det sker. Hvis det er går ned, og man starter computeren igen og
kører samme fil virker det altid! Det får mig til at overveje at der er et
eller andet sted i excell, hvor der bliver "talt op", og hvor jeg til sidst
får en for høj værdi. Jeg benytter meget få variable i mit program og har
godt styr på dem, så jeg går ud fra at det ikke kan være en variabel jeg har
erklæret der er årsagen.

Jeg har også sat msgbokse op før hver del, der fortæller hvor meget
hukommelse excell har til rådighed. Den har rigeligt med memory (der er for
øvrigt 122 MB i computeren). Samtidig kan jeg se at antallet af brugte bytes
er nogenlunde konstant efter hver del og hver fil.

Det er meget vanskeligt at følge en stepvise udførelse fordi excell skal
have arbejdet flere minutter før det går galt.

Endnu et hint: Da jeg prøvede at slå opdateringen af skærmen under
udførelsen af programmet fra, kunne excell klare flere filer før den gik
ned.

Er der nogle der har nogen gode ideer til hvad der kan være galt?
Er der nogen der ved om man kan rense hukommelsen (uden at lukke computeren
ned)?

Mange hilsner

Søren Jensen

---

Søren Jensen skrev:
> Jeg har et problem med et program jeg har lavet i visual basic til Excel
97:
> Det går ned som følge af out of memory. Og den går ikke bare ned, men ned
> med et brag...

....så må du skrue lidt ned for højttalerne.

Det lyder som om du er løbet ind i et rigtigt grimt "memory leak", og du er
ikke den første der har prøvet den slags.

Ofte bliver den slags rettet med tiden, og Excel 97 har efterhånden nogle år
på bagen, så derfor:

Har du lagt diverse service packs (1 og 2a så vidt jeg husker) på din Excel?
Hvilket OS bruger du?
Har dit OS de nyeste service packs?

-------
Tomas

---

Jeg kender udmærket det problem. Jeg har næsten revet håret af mit hovedet i
irritation over det problem. Det har noget med den konventionelle hukommelse
at gøre. Dvs. Overførsel af data fra et VB program til Excel 97 går åbenbart
via den noget begrænset konventionelle hukommelse som jo bekendt ligger på
omkring 650 kb minus det den så bruger på dvs. objekter, programmer, data
etc. så i bund og grund ligger den vel under de 600 kb. Du kan smide nok så
meget RAM i maskinen, det hjælpe intet. Trust me, jeg har prøvet det. Jeg
har ligeledes søgt i dagevis på internettet for at finde en eller anden
guru, som lige kendte svaret på dette problem. Men niks, intet.

Jeg har nu fundet en løsning, nok ikke den mest geniale, men det kan jo
tænkes at du kan bruge den. Jeg lægger data over i en Access fil, som jeg
derefter i VB programmet, læser over i et Excel ark. Det virker sgu, og
endda utroligt hurtigt. Faktisk hurtigere end min direkte dataoverførsel fra
VB til Excel.

Min rutine ser nogenlunde sådan ud:

Dim cnt As New ADODB.Connection
Dim rst As New ADODB.Recordset
Dim MyXL As Object ' Variable to hold reference

Dim xlApp As Object
Dim xlWb As Object
Dim xlWs As Object

Dim recArray As Variant

Dim strDB As String
Dim fldCount As Integer
Dim recCount As Long
Dim iCol As Integer
Dim iRow As Integer

strDB = App.Path & "\LS.MDB"

' Open connection to the database
cnt.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & "Data Source=" & strDB &
";"

' Open recordset based on Orders table
rst.Open "Select * From BHJLGLS3", cnt

' Create an instance of Excel and add a workbook
Set xlApp = CreateObject("Excel.Application")
Set xlWb = xlApp.Workbooks.Add
Set xlWs = xlWb.Worksheets("Ark1")

' Display Excel and give user control of Excel's lifetime
xlApp.Visible = True
xlApp.UserControl = True

' Copy field names to the first row of the worksheet
fldCount = rst.Fields.Count
For iCol = 1 To fldCount
xlWs.Cells(1, iCol).Value = rst.Fields(iCol - 1).Name
Next

' Check version of Excel
If Val(Left$(xlApp.Version, 1)) > 8 Then
'EXCEL 2000: Use CopyFromRecordset

' Copy the recordset to the worksheet, starting in cell A2
xlWs.Cells(2, 1).CopyFromRecordset rst
'Note: CopyFromRecordset will fail if the recordset
'contains an OLE object field or array data such
'as hierarchical recordsets

Else
'EXCEL 97 or earlier: Use GetRows then copy array to Excel

' Copy recordset to an array
recArray = rst.GetRows
'Note: GetRows returns a 0-based array where the first
'dimension contains fields and the second dimension
'contains records. We will transpose this array so that
'the first dimension contains records, allowing the
'data to appears properly when copied to Excel

' Determine number of records
recCount = UBound(recArray, 2) + 1 '+ 1 since 0-based array

' Check the array for contents that are not valid when
' copying the array to an Excel worksheet
For iCol = 0 To fldCount - 1
For iRow = 0 To recCount - 1
' Take care of Date fields
If IsDate(recArray(iCol, iRow)) Then
recArray(iCol, iRow) = Format(recArray(iCol, iRow))
' Take care of OLE object fields or array fields
ElseIf IsArray(recArray(iCol, iRow)) Then
recArray(iCol, iRow) = "Array Field"
End If
Next iRow 'next record
Next iCol 'next field

' Transpose and Copy the array to the worksheet,
' starting in cell A2
xlWs.Cells(2, 1).Resize(recCount, fldCount).Value =
TransposeDim(recArray)
End If

' Auto-fit the column widths and row heights
xlApp.Selection.CurrentRegion.Columns.AutoFit
xlApp.Selection.CurrentRegion.Rows.AutoFit

' Close ADO objects
rst.Close
cnt.Close
Set rst = Nothing
Set cnt = Nothing

' Release Excel references
Set xlWs = Nothing
xlWb.SaveAs "C:\lagerliste\lagerliste.xls"
Set xlWb = Nothing
xlApp.Quit
Set xlApp = Nothing

Jeg håber at du kan bruge lidt af det. Det var ihvertfald med til at skubbe
mig lidt videre i mit projekt.

Venlig hilsen
Tommy Jensen


"Søren Jensen" <FogS_sake@mail.tele.dk> skrev i en meddelelse
news:954326$5l8$1@news.inet.tele.dk...
> Hej Gruppe
>
> Jeg har et problem med et program jeg har lavet i visual basic til Excel
97:
> Det går ned som følge af out of memory. Og den går ikke bare ned, men ned
> med et brag - computeren fryser, fejlmeddelelsen bliver ikke vist i en pæn
> dialogboks, men derimod i den grimme hvide kasse og man skal afbryde på
> powerknappen for at komme ud.
>
> Programmet er opbygget som følger:
> 1 del. Åbner en fil, laver en masse forskellige operationer på regnearket
> (den tungeste del)
> 2 frl. Retter lidt i opsætning, skriver filen ud, lukker den, og åbner den
> næste.. OSV.
>
> Det er altid i del 1 programmet går ned. En del af problemet er at
> programmet aldrig går ned samme sted. Det skal altid have kørt mindst 3-4
> filer før det sker. Hvis det er går ned, og man starter computeren igen og
> kører samme fil virker det altid! Det får mig til at overveje at der er et
> eller andet sted i excell, hvor der bliver "talt op", og hvor jeg til
sidst
> får en for høj værdi. Jeg benytter meget få variable i mit program og har
> godt styr på dem, så jeg går ud fra at det ikke kan være en variabel jeg
har
> erklæret der er årsagen.
>
> Jeg har også sat msgbokse op før hver del, der fortæller hvor meget
> hukommelse excell har til rådighed. Den har rigeligt med memory (der er
for
> øvrigt 122 MB i computeren). Samtidig kan jeg se at antallet af brugte
bytes
> er nogenlunde konstant efter hver del og hver fil.
>
> Det er meget vanskeligt at følge en stepvise udførelse fordi excell skal
> have arbejdet flere minutter før det går galt.
>
> Endnu et hint: Da jeg prøvede at slå opdateringen af skærmen under
> udførelsen af programmet fra, kunne excell klare flere filer før den gik
> ned.
>
> Er der nogle der har nogen gode ideer til hvad der kan være galt?
> Er der nogen der ved om man kan rense hukommelsen (uden at lukke
computeren
> ned)?
>
> Mange hilsner
>
> Søren Jensen
>
>

---

"Tommy Erik Jensen" <tommyerik@jensen.mail.dk> skrev i en meddelelse
news:9bvka0$57n$3@news.inet.tele.dk...
> Jeg kender udmærket det problem. Jeg har næsten revet håret af mit hovedet
i
> irritation over det problem. Det har noget med den konventionelle
hukommelse
> at gøre. Dvs. Overførsel af data fra et VB program til Excel 97 går
åbenbart
> via den noget begrænset konventionelle hukommelse som jo bekendt ligger på
> omkring 650 kb minus det den så bruger på dvs. objekter, programmer, data
> etc. så i bund og grund ligger den vel under de 600 kb. Du kan smide nok
så
> meget RAM i maskinen, det hjælpe intet. Trust me, jeg har prøvet det. Jeg
> har ligeledes søgt i dagevis på internettet for at finde en eller anden
> guru, som lige kendte svaret på dette problem. Men niks, intet.
>
Hvis det drejer sig om for lidt konventionel hukommelse bør man kunne
optimere denne, med mindre man bruger Win Me. I de øvrige versioner kan man
normalt lave bl.a. følgende:

I config.sys ændres der til følgende indhold
DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE noems
DOS=High
DOS=UMB
devicehigh=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=045,850,C:\WINDOWS\COMMAND\country.sys
Hvis du har andet stående, må du for guds skyld ikke slette det, men
ovenstående bør minimum stå der.
I autoexec.bat kan der stå

mode con codepage prepare=((850) C:\WINDOWS\COMMAND\ega.cpi)
mode con codepage select=850
lh keyb dk,,C:\WINDOWS\COMMAND\keyboard.sys

Du kan åbne og redigere disse filer bl.a. med notesblok. Kommaer og
mellemrum skal stå nøjagtigt, ellers virker det ikke.
Du kan evt. kopier og indsætte direkte her fra denne mail.
Skulle du have andre spændende ting stående i din config.sys eller
autoexec.bat kan disse formentlig også optimeres til at bruge øvre
hukommelse i stedet for. I config.sys kan man udskifte alle de steder, hvor
der står device=
med devicehigh= Undtagen i de 2 linier som jeg har skrevet ovenstående.
Hvis noget skal og kan flyttes i autoexec.bat skal du bruge LH (loadhigh)
først i linien.
Post evt. din config.sys og autoexec.bat, så skulle det være mærkeligt, om
ikke der kan vrides mindst 600 kb fri konventionel hukommelse ud af den.

Kurt
Kurt

---

Hej venner

Tak for hjælpen. Den kom desværre lidt sent, så jeg endte med at skrive
programmet radikalt om (og jeg blev nødt til at køre programmet på meget
mindre stykker data). Jeg har derfor ikke testet jeres løsninger. Jeg undrer
mig
over det du skriver Kurt, da jeg troede at windows ignorerede config.sys og
autoexec.bat fra og med windows 95 - dvs. at det kun var når man kørte
programmer under en dos-promt at de to filer betød noget.

I mellemtiden har jeg også læst om folk der anbefaler at rydde op i koden
ved at copy og paste igen som tekst, og dermed undgå "out of Memory".

Anyway, hvis jeg får problemet igen er jeg noget bedre forberedt. Igen: Tak
for
hjælpen.

Hilsen Søren


Kurt B. Andersen <kurta@iname.com> skrev i en
nyhedsmeddelelse:NOIE6.499$S4.193966@news101.telia.com...
>
> "Tommy Erik Jensen" <tommyerik@jensen.mail.dk> skrev i en meddelelse
> news:9bvka0$57n$3@news.inet.tele.dk...
> > Jeg kender udmærket det problem. Jeg har næsten revet håret af mit
hovedet
> i
> > irritation over det problem. Det har noget med den konventionelle
> hukommelse
> > at gøre. Dvs. Overførsel af data fra et VB program til Excel 97 går
> åbenbart
> > via den noget begrænset konventionelle hukommelse som jo bekendt ligger
på
> > omkring 650 kb minus det den så bruger på dvs. objekter, programmer,
data
> > etc. så i bund og grund ligger den vel under de 600 kb. Du kan smide nok
> så
> > meget RAM i maskinen, det hjælpe intet. Trust me, jeg har prøvet det.
Jeg
> > har ligeledes søgt i dagevis på internettet for at finde en eller anden
> > guru, som lige kendte svaret på dette problem. Men niks, intet.
> >
> Hvis det drejer sig om for lidt konventionel hukommelse bør man kunne
> optimere denne, med mindre man bruger Win Me. I de øvrige versioner kan
man
> normalt lave bl.a. følgende:
>
> I config.sys ændres der til følgende indhold
> DEVICE=C:\WINDOWS\HIMEM.SYS
> DEVICE=C:\WINDOWS\EMM386.EXE noems
> DOS=High
> DOS=UMB
> devicehigh=C:\WINDOWS\COMMAND\display.sys con=(ega,,1)
> Country=045,850,C:\WINDOWS\COMMAND\country.sys
> Hvis du har andet stående, må du for guds skyld ikke slette det, men
> ovenstående bør minimum stå der.
> I autoexec.bat kan der stå
>
> mode con codepage prepare=((850) C:\WINDOWS\COMMAND\ega.cpi)
> mode con codepage select=850
> lh keyb dk,,C:\WINDOWS\COMMAND\keyboard.sys
>
> Du kan åbne og redigere disse filer bl.a. med notesblok. Kommaer og
> mellemrum skal stå nøjagtigt, ellers virker det ikke.
> Du kan evt. kopier og indsætte direkte her fra denne mail.
> Skulle du have andre spændende ting stående i din config.sys eller
> autoexec.bat kan disse formentlig også optimeres til at bruge øvre
> hukommelse i stedet for. I config.sys kan man udskifte alle de steder,
hvor
> der står device=
> med devicehigh= Undtagen i de 2 linier som jeg har skrevet ovenstående.
> Hvis noget skal og kan flyttes i autoexec.bat skal du bruge LH (loadhigh)
> først i linien.
> Post evt. din config.sys og autoexec.bat, så skulle det være mærkeligt, om
> ikke der kan vrides mindst 600 kb fri konventionel hukommelse ud af den.
>
> Kurt
> Kurt
>
>
>
>
>

---

"Søren Jensen" <soeren.jensen@mail.tele.dk> skrev i en meddelelse
news:9chali$889$1@news.inet.tele.dk...
> Hej venner
>
> Tak for hjælpen. Den kom desværre lidt sent, så jeg endte med at skrive
> programmet radikalt om (og jeg blev nødt til at køre programmet på meget
> mindre stykker data). Jeg har derfor ikke testet jeres løsninger. Jeg
undrer
> mig
> over det du skriver Kurt, da jeg troede at windows ignorerede config.sys
og
> autoexec.bat fra og med windows 95 - dvs. at det kun var når man kørte
> programmer under en dos-promt at de to filer betød noget.
>
Så troede du forkert Fra windows 95 sagde man, at nu behøvede man ikke at
bekymre sig om autoexec.bat og config.sys, idet der stod det der skulle til.
Men man siger jo så meget hver gang en ny win kommer til. Især ved win95 var
der mange, som stadig havde dosspil og programmer, som krævede særlig
opsætning, og den kunne kun ændres via disse filer. Langt de fleste kunne
man køre direkte inde i win95 og derfor skulle autoexec.bat og config.sys
selvfølgelig virke, hvilket de også gjorde. I win95 kunne man desuden lave
nogle specielle autoexec.bat og config.sys, som kun blev kaldt, hvis man gik
i ren dos. Jeg har gang på gang oplevet forskellige problemer også under
win98, hvor der manglede konventionel memory, hvorfor man var nødt til at
tune sin autoexec.bat og config.sys lidt, og det var altså for at det skulle
slå igennem inde i windows.
Men nu er WinMe kommet, og der kan man skrive hvad man vil i autoexec.bat og
config.sys uden at windows bruger det. Enkelte ting vil den dog flytte over
i typisk win.ini i stedet, mens andre ting ignoreres.
Man kan heller ikke boote til ren dos.
Dog er der dygtige folk, som har opfundet en patch, så man dels kan få fat i
noget der næsten er identisk med gammel dos (ligger gemt inde i WinMe) og
derefter kan skrive sin autoexec.bat og config.sys som man har lyst.
Jeg har hentet patchen, men har ikke turdet prøve den, da den formentlig kun
virker i den engelske version.
Men det vil jeg nok alligevel forsøge i nær fremtid umiddelbart efter at jeg
har taget et image af c-drevet, så jeg evt. kan få genetableret hurtigt,
hvis der går rigtig ged i det.

Kurt
Kurt

---

"Søren Jensen" <soeren.jensen@mail.tele.dk> skrev i en meddelelse
news:9chali$889$1@news.inet.tele.dk...

> I mellemtiden har jeg også læst om folk der anbefaler at rydde
op i koden
> ved at copy og paste igen som tekst, og dermed undgå "out of
Memory".

Hvis det den type problem du har, så har jeg et link til et
program, som du ikke kan undvære, hvis du programmerer større
programmer i VBA i Excel.

http://www.bmsltd.co.uk/MVP/Default.htm

.... Kig efter CodeCleaner.exe - det er guld værd.

--

/\ preben nielsen
\/\ prel@post.tele.dk