[VB] error 6 overflow

[Verwijderd]

Ik heb een programma in visual basic geschreven. Programma draait denk ik op een 10 tal computers. Jaar geleden geinstalleerd en draait sinsdien goed. Tot gisteren. Blijkt dat er op een 2-tal computers sinds gisteren niet meer mogelijk is om records in een oracle database op te slaan. (het is VB programma met koppeling tussen Oracle via ODBC) Melding die verschijnt is:

Run-time error 6 - Overflow

De melding blijkt op 1 computer te verhelpen te zijn door wat andere programma's af te sluiten. Verder is het zo dat er enkele ADODC op het formulier staan via welke qwery's uitgevoerd worden op de database. Deze wordt pas gesloten als het programma wordt afgesloten. Kan het zo zijn dat je telkens na een qwery de koppeling met de database weer moet sluiten of iets dergelijks omdat er anders een overflow (vol geheugen etc) zou kunnen ontstaan?

[RobIII]

Wellicht zit het probleem in een autonummering veld ofzo dat over de 2147483647 heen is gegaan (Long) of over de 32767 (Integer). Dan krijg je overflows. Een geheugenprobleem lijkt me, hoewel niet onmogelijk, sterk. Check dus eerst eens of je al je boundaries goed hebt afgebakend (en gechecked).

offtopic:
Het is queries, niet qwery's

code:

Dim i As Integer
Dim l As Long

i = 32767
i = 32768   'Error....

l = 2147483647
l = 2147483648 'Error....

[ Voor 25% gewijzigd door RobIII op 30-12-2004 13:50 ]

[Verwijderd]

Ik heb gekeken naar de waarde van het Id veld (sleutel) deze is nog net binnen de waarde van een integer. Ik heb er een long van gemaakt. Het probleem blijft. Aangezien hetzelfde programma op 2 computers niet goed meer werkt maar op de overige nog wel heeft het denk ik eerder iets met het geheugen van die computers te maken dan met de variable declaratie in programma. Hoe kan ik zien welke elementen in mijn VB applicatie veel geheugen nodig hebben of welke punten in mijn programma op dat gebied verbeterd moeten worden? Is er een tool om deze dingen te meten? Ik heb verder in de procedure waar het fout gaat geen rare grote hoeveelheden gegevens, enkel een paar strings en andere variabele die opgeslagen worden in een record van de Oracle DB.

[P_de_B]

Je zult toch moeten debuggen en kijken waar het probleem zich precies voordoet. Heb je die mogelijkheid?

[Tukk]

Verwijderd schreef op donderdag 30 december 2004 @ 16:10:
Ik heb gekeken naar de waarde van het Id veld (sleutel) deze is nog net binnen de waarde van een integer. Ik heb er een long van gemaakt. Het probleem blijft. Aangezien hetzelfde programma op 2 computers niet goed meer werkt maar op de overige nog wel heeft het denk ik eerder iets met het geheugen van die computers te maken dan met de variable declaratie in programma. Hoe kan ik zien welke elementen in mijn VB applicatie veel geheugen nodig hebben of welke punten in mijn programma op dat gebied verbeterd moeten worden? Is er een tool om deze dingen te meten? Ik heb verder in de procedure waar het fout gaat geen rare grote hoeveelheden gegevens, enkel een paar strings en andere variabele die opgeslagen worden in een record van de Oracle DB.

Om te kunnen bepalen wat je probleem is kun je na gaan wat het verschil is tussen die twee pcs en de rest.

• Draait er op die pc's andere software(denk ook aan ADO-versies, enz.)
• Worden er andere acties uitgevoerd op die twee pc's? (oa. andere queries)

Wat ook zou kunnen is dat je in een loop objecten blijft aanmaken, mischien kan Taskmanaher je wat meer vertellen tijdens een crash. Taskmanager geeft niet alleen geheugen gebruik weer, maar ook handles en andere parameter die handig zijn om te bekijken tijdens het testen van je software.

Verder heeft Sysinternals.com handige tooltjes om achter de moeilijkere bugs te komen.

[ Voor 7% gewijzigd door Tukk op 30-12-2004 16:17 ]

[Janoz]

De foutmelding 'overflow' geeft aan dat er ergens een te groot getal in wordt gestopt. Het heeft niks te maken met te weinig geheugen of te grote structuren (dat is 'out of memory')!! Bedenk wel dat het aanpassren van het type in de database alleen niet de oplossing is aangezien de foutmelding binnen je applicatie optreed.

[Verwijderd]

P_de_B schreef op donderdag 30 december 2004 @ 16:12:
Je zult toch moeten debuggen en kijken waar het probleem zich precies voordoet. Heb je die mogelijkheid?

Helaas heb ik die mogelijkheid niet. Bij mij thuis draait alles perfect. Dat maakt het probleem ook zo lastig. Ik denk te weten in welke procedure het fout gaat, die waar de record wordt opgeslagen in de Oracle database.

[H!GHGuY]

je zal zoals janoz zegt in de broncode van het programma de ID-waarden van een int naar een long zetten (of unsigned long voor nog meer plezier)

[Verwijderd]

Janoz schreef op donderdag 30 december 2004 @ 16:18:
De foutmelding 'overflow' geeft aan dat er ergens een te groot getal in wordt gestopt. Het heeft niks te maken met te weinig geheugen of te grote structuren (dat is 'out of memory')!! Bedenk wel dat het aanpassren van het type in de database alleen niet de oplossing is aangezien de foutmelding binnen je applicatie optreed.

Ik heb de ID waarde van int naar long gezet in het programma. Opnieuw gecompuleerd, maar het probleem treed nog steeds op. Kan het zo zijn dat het probleem zich in de Oracle database bevind? Of kan het zo zijn dat ik als ik een int in een long aanpas in mijn code ook in de tabellen van de oracle database iets moet aanpassen? Hoe kan het dat er alleen overflow optreed op een 2 tal computers maar op alle andere die dezelfde bewerkingen uitvoeren er geen problemen zijn met het opslaan?

[RobIII]

HIGHGuY schreef op donderdag 30 december 2004 @ 16:23:
je zal zoals janoz zegt in de broncode van het programma de ID-waarden van een int naar een long zetten (of unsigned long voor nog meer plezier)

VB6 kent geen unsigned types ... De makkelijkste "workaround" daarvoor is gewoon een type groter pakken byte -> integer -> long -> currency/decimal -> deep_trouble

Verwijderd schreef op donderdag 30 december 2004 @ 16:28:
Ik heb de ID waarde van int naar long gezet in het programma. Opnieuw gecompuleerd

Opnieuw gecompileerd denk ik

Verwijderd schreef op donderdag 30 december 2004 @ 16:28:
maar het probleem treed nog steeds op.

Ik neem aan dat je je app ook opnieuw hebt gedistribueerd?

Verwijderd schreef op donderdag 30 december 2004 @ 16:28:
Kan het zo zijn dat het probleem zich in de Oracle database bevind?

Alles kan, jij zult het moeten zoeken...

Verwijderd schreef op donderdag 30 december 2004 @ 16:28:
Of kan het zo zijn dat ik als ik een int in een long aanpas in mijn code ook in de tabellen van de oracle database iets moet aanpassen?

Lijkt me wel verstandig om je interne types overeen te laten komen met de types die je in Oracle gebruikt (dat kan helaas niet altijd als je met databases werkt, maar vaak wel).

Verwijderd schreef op donderdag 30 december 2004 @ 16:28:
Hoe kan het dat er alleen overflow optreed op een 2 tal computers maar op alle andere die dezelfde bewerkingen uitvoeren er geen problemen zijn met het opslaan?

Dat weet alleen jij. Wat is het verschil tussen die twee computers en de rest? OS? ADO versies? Andere componenten?

Wat je ook kunt doen (effe ranzig, maar wel makkelijk) is om in de procedure waar je denkt dat het fout gaat om de zoveel regels code een MsgBox te zetten (MsgBox "A" en dan MsgBox "B" enz). Je ziet dan dat je programma bijv. tot "F" komt en dan klapt... Dan weet je dat het in die regels erna zit, tot en met MsgBox "G".

Wil je het netter doen dan gebruik je gewoon nette errorhandling (on error goto errSomething is "netjes" in VB6 ) en log je je error naar het eventlog of een bestand ofzo. Als je dan ook nog bijhoudt met welke bewerking je op dat moment bezig was (in een variabele ofzo) en je schrijft die ook weg, dan kom je al een heel eind. Debuggen heet dat

Ik neem aan dat ik "duidelijk" genoeg ben geweest. Mocht je niet begrijpen wat ik bovenstaande 2 alinea's bedoel, dan maak ik wel een voorbeeldje (vb'tje )

Ashtaroth schreef op donderdag 30 december 2004 @ 17:26:
En als je dan toch aan het debuggen bent, is het loggen van de regelnummer nog mooier dan eerdere alternatieven die werden geopperd.

Voeg regelnummers toe in je code en vraag deze met Erl uit in je error handler.

Suc6

<rilling>

[ Voor 21% gewijzigd door RobIII op 30-12-2004 20:12 ]

[Ashtaroth]

En als je dan toch aan het debuggen bent, is het loggen van de regelnummer nog mooier dan eerdere alternatieven die werden geopperd.

Voeg regelnummers toe in je code en vraag deze met Erl uit in je error handler.

Suc6

[farlane]

RobIII schreef op donderdag 30 december 2004 @ 17:06:
<rilling>

Dat kan bij een moeilijk te traceren bug toch echt wel heel handig werken. Nog mooier zou zijn dat je vaste ( preprocessor )variabelen zou hebben ( __FILE__, __LINE__) die aangeven waar het programma zich bevindt, net als in C.

[RobIII]

farlane schreef op donderdag 30 december 2004 @ 21:05:
[...]


Dat kan bij een moeilijk te traceren bug toch echt wel heel handig werken. Nog mooier zou zijn dat je vaste ( preprocessor )variabelen zou hebben ( __FILE__, __LINE__) die aangeven waar het programma zich bevindt, net als in C.

Oh, zo bedoel ik het ook niet. Natuurlijk kan het handig zijn, maar het doet mij altijd aan ouwe ranzige code denken met goto's naar die linenumbers

[farlane]

RobIII schreef op donderdag 30 december 2004 @ 22:34:
Oh, zo bedoel ik het ook niet. Natuurlijk kan het handig zijn, maar het doet mij altijd aan ouwe ranzige code denken met goto's naar die linenumbers

Ik begrijp de associatie