[VB6] Deleten van Records in je eigen bestandstypen

[roy-t]

Ik ben bezig met een programma maken dat eens in de zoveeltijd moet communiceren met een ftp, omdat er echt een rot meuk aan records aan zit te komen wil ik dit zo klein mogelijk houden, nu heb ik het volgende stukje code om iets op te slaan:

code:

Open App.Path & "\Overig\Personeel.SDS" For Random As #1 Len = Len(Personeel)
Get #1, Personeel.ID, Personeel
Close #1

Maar nu wil ik een record echt weg hebben, ik zou met een boolean in het type Personeel kunnen zeggen dat iets wel of niet mee doet (negeren als boolean = true ofzoiets) maar hier haal ik de records zelf niet mee weg.

Ik zoek dus eigenlijk naar:

code:

Open App.Path & "\Overig\Personeel.SDS" For Random As #1 Len = Len(Personeel)
DELETE #1, Personeel.ID, Personeel
Close #1

Maar ik kan echt nergens ook maar een instructie vinden om dit voor elkaar te krijgen. niet in de MSDN, niet in "Het Complete Visual Basic 6 Handboek" van Brian Siler en ook niet via Google (waar ik een hoop valse hits krijg mbt Acces en VB6)

Bestandsgrote is echt belangrijk voor dit project, en het is altijd slordig om een programma te schrijven met een neppe delete code (hallo langzame grote bestanden) nu kan ik ook met een boolean aangeven of een record overschreven zou mogen worden, en opzich de schade beperken, maar is er iemand die een stuk nette code kan bedenken om gewoon een record te deleten, ik kan het echt niet vinden, maar het ook meteen niet geloven dat dat er niet is!

[StevenK]

Wanneer je in een sequentieel bestand een regel wilt verwijderen, moet je gewoon vanaf die regel het bestand opnieuw vullen.

[elevator]

Wat je normaal moet doen (tenzij VB daar iets speciaals voor heeft ) is gewoon heel je bestand opnieuw schrijven waarbij je het gewiste record weglaat.

[pistole]

therat10430 schreef op zondag 29 oktober 2006 @ 12:52:
Bestandsgrote is echt belangrijk voor dit project, en het is altijd slordig om een programma te schrijven met een neppe delete code (hallo langzame grote bestanden)

Het lijkt me ook slordig om het wiel opnieuw uit te vinden. Waarom knoop je er geen mdb filetje aan ofzo?

[RobIII]

Wat omslachtig allemaal; wat ik zo zie aan je code is dat je een vaste recordlengte gebruikt. Als je dan een record "wist" dan pak je het laatste record en move je het over het record dat je wil wissen; daarna kap je het bestand af et voila. Scheelt een heel bestand herschrijven.

Enige nadeel is dat je bestand wat "gefragmenteerd" raakt; dit kun je oplossen door (bijv. bij afsluiten van je app, of via een manuele handeling) je bestand af en toe te "defragmenteren" (als in: nieuw bestand aanleggen, records in de juiste volgorde erin gooien, origineel weggooien en nieuw renamen naar origineel et voila). En da's dus alleen maar van toepassing als het uberhaupt belangrijk is in welke volgorde je records staan.

Euh... come to think of it: in VB6 kun je volgens mij geen file "truncaten" zonder naar API's (SetEndOfFile) te moeten grijpen

Wellicht hier maar eens kijken. Ze zijn momenteel in "halloween" stemming, maar doorgaans is dit best een te aanschouwen site met erg veel handige VB6 snippets. *

Verder zie ik je "hard" #1 gebruiken: als je het dan toch netjes wil doen, gebruik dan de FreeFile functie om een vrije file handle te krijgen. Wel zo netjes

pistole schreef op zondag 29 oktober 2006 @ 12:55:
[...]

Het lijkt me ook slordig om het wiel opnieuw uit te vinden. Waarom knoop je er geen mdb filetje aan ofzo?

Als je alleen daarvoor een mdb gaat gebruiken vind ik het nogal een lompe oplossing; als je er nou nog meer functionaliteit uit haalt (als in je mdb ook daadwerkelijk gebruiken als database) dan heeft het wellicht nog nut.

* En dan doel ik dus hier op:

Visual Basic:

Private Sub DeleteLastRandomRecord()
   Dim td As TestData
   Dim hfile As Long
   Dim totalrecords As Long
   Dim newfilesize As Long
   Dim dwFileSizeLow As Long
   Dim dwFileSizeHigh As Long
      
  'how many records in the file?
   totalrecords = FileLen(sTestFile) \ Len(td)
  'can't truncate the file if totalrecords is less than 2
   If totalrecords >= 2 Then
     'open the file using the API
      hfile = CreateFile(sTestFile, _
                          GENERIC_WRITE Or GENERIC_READ, _
                          0&, ByVal 0&, _
                          OPEN_ALWAYS, _
                          FILE_ATTRIBUTE_NORMAL, _
                          0&)
     'Get the file size. Note that the value returned is the size of the file asstored in the low word of GetFileSize with
     'the high word returning 0. This will accommodate most reasonably-sized files. If the file is large, however, then the low
     'and high word values have to be be combined to get the actual size. This demo assumes a you're using a reasonably sized random access
     'file, so a test of dwFileSizeHigh is made to ensure it is 0 before truncating.
      dwFileSizeLow = GetFileSize(hfile, dwFileSizeHigh)
      If dwFileSizeHigh = 0 Then
        'dwFileSizeLow for this test is the file size; one record is Len(td), so in order to delete the last
        'record the new size is the current size minus the length of one record:
         newfilesize = dwFileSizeLow - Len(td)
         Debug.Print totalrecords, dwFileSizeLow, newfilesize
        'now move the file pointer to the new end position ..
         If SetFilePointer(hfile, newfilesize, dwFileSizeHigh, FILE_BEGIN) > 0 Then
           'and "delete" the last record by changing the end of file marker
            Call SetEndOfFile(hfile)
         End If  'SetFilePointer
      End If  'dwFileSizeHigh
      CloseHandle hfile
   End If
End Sub

[ Voor 99% gewijzigd door RobIII op 29-10-2006 13:11 ]

[roy-t]

Bedankt allemaal voor jullie reacties!

Elevator: Wat je normaal moet doen (tenzij VB daar iets speciaals voor heeft ) is gewoon heel je bestand opnieuw schrijven waarbij je het gewiste record weglaat.

Dit lijkt mij de makkelijkste manier zonder echt een bult truncate code te schrijven, stom dat ik daar niet aan gedacht heb! (sommige oplossingen zijn zo simpel doh!)

@ Pistole, ik gebruik geen mdb omdat ik de extra functionaliteit niet nodig heb voor een paar bestandjes, en omdat ik zo directe controle heb op de grote van het bestand

@ RobIII hardstikke bedankt voor die link, daar zijn inderdaad mooie voorbeeldjes te vinden (eeuuwwll die halloween stijl, maar goed ) Ik ga je oplossing niet gebruiken denk ik, omdat het ondanks dat het misschien de beste code is, ook een beetje omslachtig is in vergelijking met het bestand gewoon opnieuw (over) schrijven.

Ik gebruik btw hard een file nummer omdat ik eigenlijk maar 1 file tegelijkertijd open heb, dan lijkt freefile me een beetje omslachtig (hoewel het ook werkt natuurlijk)

Hardstikke bedankt voor jullie reacties, nu aan het programmeren!

[RobIII]

therat10430 schreef op maandag 30 oktober 2006 @ 12:40:
Ik gebruik btw hard een file nummer omdat ik eigenlijk maar 1 file tegelijkertijd open heb, dan lijkt freefile me een beetje omslachtig (hoewel het ook werkt natuurlijk)

Harde file handles zijn nooit netjes, en wat is hier omslachtig aan?

Visual Basic:

Dim FF as integer

FF = FreeFile
Open ..... as #FF ...

[roy-t]

Daar ben ik het niet mee eens, een hardefile handle zou niet netjes zijn bij het behandelen van meerdere bestanden, maar als je echt puur in 1 bestand werkt is het makkelijk om gewoon 1 te gebruiken. Het scheelt ook weer net 3 regels code, wat handig is voor mijn programma omdat het echt zo klein mogelijk moet zijn.

(ook lijkt het me makkelijker om resources te besparen, ipv 1 global variabele freefile, gewoon telkens het nummer "1" in typen, nu is dat misschien nog niet eens 1 bit extra maar alle beetjes helpen!!)

[kenneth]

Alle programma's beginnen klein
Het kan geen kwaad om dit soort best practices aan te leren door ze altijd te gebruiken.

[RobIII]

therat10430 schreef op maandag 30 oktober 2006 @ 14:22:
Daar ben ik het niet mee eens, een hardefile handle zou niet netjes zijn bij het behandelen van meerdere bestanden, maar als je echt puur in 1 bestand werkt is het makkelijk om gewoon 1 te gebruiken.

Bull, een harde file-handle is NOOIT netjes. Wat als je programma "uitgroeit"? Wat als je programma straks door anderen onderhouden wordt? Of als je straks met meer mensen in de source zit te frotten? Of als je zelf over 2 jaar je eigen code weer eens moet aanpassen? Dan gaat het gegarandeerd een keer fout; want dan weet jij (of je collega of....) het niet meer en gaat iemand anders ook doodleuk #1 zitten gebruiken (hoewel die overigens ook FreeFile had moeten gebruiken dan )

therat10430 schreef op maandag 30 oktober 2006 @ 14:22:
Het scheelt ook weer net 3 regels code, wat handig is voor mijn programma omdat het echt zo klein mogelijk moet zijn.

Ten eerste is het aantal regels code niet evenredig met de grootte van een binary; ten tweede zul je zien dat het geen moer uit maakt omdat VB6 altijd executables uitpoept in groottes van een veelvoud van 4Kb ofzo (kan er naast zitten, maar zoiets is het) dus die paar bytes die het extra kost worden waarsch. gewoon in de "slack" ruimte gegooid en je zult het niet merken aan je executable size. Los daarvan; als het écht zo belangrijk is dat je app in zo min mogelijk bytes draait dan moet je geen VB6 gebruiken
Als we het gaan hebben over "performance" (als in: dat je dit performance/cpu cycles zou kosten); ja, het kost je een paar CPU cycles en nee, het is niet meetbaar en al helemaal niet "merkbaar" voor de gebruiker (tenzij je het duizenden keren per sec. aanroept misschien) op een enkele aanroep. Dus ook dat is geen reden om freefile achterwege te laten.
En dan nog is het gewoon, zoals boven mij ook al gezegd wordt, best-practice.

therat10430 schreef op maandag 30 oktober 2006 @ 14:22:
(ook lijkt het me makkelijker om resources te besparen, ipv 1 global variabele freefile, gewoon telkens het nummer "1" in typen, nu is dat misschien nog niet eens 1 bit extra maar alle beetjes helpen!!)

Wederom bull; lees mijn stukje hierboven nog even. Zowieso zal het nooit geen "bits" schelen want je app zal altijd uit "bytes" bestaan. En verder kost een "var" van het type integer je net zo veel als een hardcoded 1 (die wordt namelijk ook gewoon naar een integer gecompiled omdat het "open as" statement een integer verwacht als parameter). En die var hoeft al helemaal niet global te zijn want je kunt 'm gewoon passen naar een functie als extra parameter.

Dit soort "mini-optimalisaties" is klinkklare onzin en als je dan ook nog weigert om een best-practice te volgen dan vloog je bij mij uit het team. Principekwestie. Simple as that
Voor die "anderhalve regel" code hoef je het niet te laten; als het nou nog 450+ regels was dan zou ik het wellicht (tijdelijk) door de vingers zien... Maar dit? Dan ben je IMHO luier dan een baksteen op een zondagmorgen. Je post bevat al meer tekens dan dat je die code even erin had geknald.

[ Voor 12% gewijzigd door RobIII op 30-10-2006 15:49 ]

[Verwijderd]

Ik denk dat je eens naar een Q(uick)basic boek moet zoeken b.v. 280 Q(uick)basic tips&trucs van Dirk Kroon.

Je zou ook een op de volgende site of sites kunnen kijken voor voorbeelden omtrend deze bestandbewerkingen.
http://www.adaworld.com/a...ermediate/randomfile.html (+/- op de helft van de pagina)
http://www.adaworld.com/a...mediate/intermediate.html (voor andere opties.)

Ik hoop dat je er iets aan hebt.

[RobIII]

Ik hoop niet dat je QuickBasic met VB6 vergelijkt? Ik heb VB6 voor veel uitgescholden (zien worden) maar dit slaat als een tang op een varken. Daarbij zie ik in het door jou aangehaalde principe van records markeren als deleted en je file opnieuw schrijven (compacten) wanneer je je records écht wil verwijderen niets wat hier niet al genoemd is. Of lees ik over iets heen?

[ Voor 9% gewijzigd door RobIII op 31-10-2006 00:45 ]

[Verwijderd]

Nee, ik vergelijk Q(uick)basic niet met VB6, de persoon van de vraag is naar mijn idee bezig met iets wat hij omslachtig wil oplossen. In dat kader denk ik dat hij op een QB manier in VB aan het programmeren is. Of het mooi is of niet dat zou hij naar mijn mening zelf moeten bedenken. Ik zelf zou het met één of andere bestaande database doen zoals b.v. de mdb files als die te groot bijken zou je ze nog kunnen splitsen en comprimeren voor dat je ze met ftp verstuurd.

[farlane]

Verwijderd schreef op dinsdag 31 oktober 2006 @ 17:47:
Nee, ik vergelijk Q(uick)basic niet met VB6, de persoon van de vraag is naar mijn idee bezig met iets wat hij omslachtig wil oplossen. In dat kader denk ik dat hij op een QB manier in VB aan het programmeren is. Of het mooi is of niet dat zou hij naar mijn mening zelf moeten bedenken. Ik zelf zou het met één of andere bestaande database doen zoals b.v. de mdb files als die te groot bijken zou je ze nog kunnen splitsen en comprimeren voor dat je ze met ftp verstuurd.

Zou je voor zoiets simpels je applicatie volgooien met dependencies op ocx'en en libraries en weet ik wat meer ? ( terwijl je applcatie er zeker niet simpelder op wordt als je met ado gaat prutsen )

Das wel raar