Formulier bijwerken i.c.m. opzoek-keuzelijst

[OctaFish]

Hallo allemaal,

Ik heb een formulier in mijn db met personeelsgegevens. Op zichzelf geen bijzonder formulier, want gebaseerd op een enkele tabel. Wel wat subformulieren erop.
Met behulp van knoppen kun je heen en weer bladeren, en de onderliggende tabel wordt ook netjes bijgewerkt als je gegevens wijzigt.

Om het zoeken te vergemakkelijken, heb ik nu een combobox op het formulier gezet, met in eerste instantie de standaardcode die Access aanmaakt, dus het bekende RecordsetClone verhaal. De keuzelijst werkt prima, als je gegevens wilt bekijken; ik kan probleemloos naar andere records switchen.
Er is echter een probleem, dat je de records niet meer kunt opslaan als je gegevens wijzigt. Ik Krijg dan het bekende dialoogvenstertje, met de opties <Naar klembord kopiëren>, of <Wijzigingen negeren>.

Om het opslaan te ondervangen, heb ik een If Me.Dirty lus toegevoegd, maar dit maakt geen verschil, ik kan nog steeds niks opslaan. Volgende aanvulling op de standaardcode was het dichtgooien van de recordset, maar ook dat biedt geen soelaas.

Heeft iemand een idee/oplossing? Ik heb al gezien dat er regelmatig over de RecordsetClone is gepost, maar ik heb niks kunnen vinden over dit specifieke probleem...

Michel

Hier de gebruikte code:

Private Sub cboTM_AfterUpdate()
Dim rs As DAO.Recordset

    If Not IsNull(Me.cboTM) Then
        'Save before move.
        If Me.Dirty Then
            Me.Dirty = False
        End If
        'Search in the clone set.
        Set rs = Me.RecordsetClone
        rs.FindFirst "[Personeelsnummer] = '" & Me![cboTM] & "'"
        If rs.NoMatch Then
            MsgBox "Niks gevonden..."
        Else
            'Display the found record in the form.
            Me.Bookmark = rs.Bookmark
        End If
        rs.Close
        Set rs = Nothing
    End If
    Me.Voornaam.SetFocus

End Sub

Op het formulier wordt de keuzelijst nog leeggemaakt; een actie die ook op de bladerknoppen wordt uitgevoerd.

Private Sub Form_Current()

    cboTM.Value = ""
    Me.Voornaam.SetFocus

End Sub

 

[Guus2005]

Jouw probleem is eenvoudig op te lossen door gebruik te maken van unbound forms.
Je kan dan geen gebruik meer maken van de wizards die je ter beschikking staan in Access, maar je moet alles zelf programmeren. Dat vindt ik zelf een groot voordeel.
Ik gebruik geen macro's (muv Autokeys en AutoExec) ik gebruik alleen bound forms als er een enkele tabel onderhouden moet worden en heb daarom totale controle over alles dat gebeurt. Ik raadt het iedereen aan.

HTH

 

[OctaFish]

Bedankt voor de reactie!

Met Unbound formulieren werk ik uiteraard ook wel, maar soms wil je nu eenmaal data op basis van een tabel bijwerken.
Het vreemde met die opzoeklijsten is, dat het bij het ene formulier feiloos werkt, en bij het andere formulier dus het probleem met het niet op kunnen slaan oplevert. Er gebeurt dus iets met de recordcloneset, die in formulier A op basis van tabel A bewerkbaar is, en bij formulier B op tabel B geen records meer kan opslaan.

Ik hou me dus nog steeds aanbevolen voor enig inzicht in dit verschijnsel!

 

[OctaFish]

Ik heb nog eens wat lopen stoeien, en ik denk dat ik de reden van het probleem wel gevonden heb: het formulier draaide op een tabel uit een SQL-server database. Als ik de keuzelijst toepas op een tabel binnen de Access dB gaat het wel goed.

Als workaround maak ik nu bij opstarten van de dB een harde kopie van de gekoppelde tabel, waar dan het formulier aan is gekoppeld met een Recordset. Met AfterUpdate procedures op de aan te passen velden werk ik dan de gekoppelde SQL-tabel bij. De oplossing is uiteraard niet ideaal, maar aangezien er niet zoveel mensen in deze database werken, is hij wel werkbaar.

Mocht iemand een definitieve oplossing weten, dan hou ik mij daar uiteraard voor aanbevolen!
De concrete omschrijving van het probleem luidt dus:

Als ik op een formulier dat is gebaseerd op een tabel uit een SQLserver database, dan kan ik op dat formulier geen opzoeklijst gebruiken, omdat de gevonden records niet meer zijn bij te werken. Microsoft geeft dan een schrijfconflict, omdat het record zogenaamd is bewerkt door een andere gebruiker. Het probleem treedt niet op bij het eerste record uit de tabel, dit is probleemloos meerde keren te bewerken en op te slaan.

Iemand een idee?

 

[Artemiss]

Hoi Michel,

Ik snap het probleem nog niet helemaal, maar ik snap je (tijdelijke) oplossing wel.
Wat ik zou doen, is die oplossing automatiseren door een tabelmaakquery te maken die wordt gedraaid bij het openen van de database.

Groetjes,

 

[OctaFish]

Hoi Frauke,

Het is ook een lastig, en vooral heel vervelend probleem. Het komt er op neer, dat ik in de frontend Access 2k database koppelingen heb naar een SQL2k database. Hierop laat ik dan een aantal formulieren los.
In beginsel werkt dit prima, maar op het personeelsformulier wilde ik een keuzelijst maken, om gemakkelijker een bepaald persoon terug te vinden. Het probleem dat nu optrad, was dus dat je wèl records kunt opzoeken, maar ze daarna niet meer kunt bewerken/opslaan. Je krijgt dan het verhaal dat het record al door een andere gebruiker is geblokkeerd. Vreemd genoeg treedt dit verschijnsel dus niet op bij het eerste record van de tabel; dat record is te allen tijde prima te bewerken en op te slaan.
Ik heb al geprobeerd om het formulier rechtstreeks op de tabel te linken, heb er al een query tussen gehangen, in de hoop dat een Access object misschien wel te bewerken zou zijn, en ook heb ik al via VB code en een recordset getracht het record op te slaan.
Alles dus zonder enige verandering in de situatie. Misschien zou het aanpassen van het type recordset (ADO of DAO) nog wat uit kunnen maken, maar vooralsnog behoor ik tot het (ongetwijfeld) grote leger, dat zich al jaren afvraagt wat daar nu het verschil tussen is, en hoe je de één of de ander dan wel tot leven wekt... Als ik een recordset declareer, zie ik twee keer Recordset staan in de variabelelijst. Which one is which?

Jouw tip had ik zelf ook al bedacht, dus nu wordt er bij het opstarten eerst een hoeveelheid data overgehaald, maar uiteraard heb ik die situatie liever niet.
Op het formulier heb ik nu bij de aanpasbare velden een AfterUpdate Event gezet, dat de gekopieerde tabel èn de SQL tabel bijwerkt, en tot dusver werkt dat prima. De gebruiker merkt er dus niet zo heel veel van. Voor mijn gevoel is de gekopieerde tabel zelfs nog een haartje sneller dan de SQL tabel...

Ik hoop, dat het probleem wat duidelijker is?

 

[linkav]

Probleem schrijfconflict

Beste is het probleem met schrijfconflict opgelost? Mag ik de eventuele oplossing weten? Ik heb hetzelfde probleem, maar kom er niet uit!

Gr
Ariane

 

[OctaFish]

Helaas.... Ik snuffel af en toe nog wel wat SQL forums af, maar een oplossing is nog geen stap dichterbij gekomen. Dus heb ik mijn tabelmaakquery nog steeds in gebruik. Heb je dat al geprobeerd?

Michel

 

[linkav]

Schrijfconflict

Neen, heb ik nog niet getest, heb wel in de tabel op de SQL-server de 'bit' velden vervangen door 'int'-velden en dat blijkt te helpen... Maar vind ik geen mooie oplossing..Bug van Microsoft??

Groetjes
Ariane

 

[OctaFish]

Ik heb je workaround voor de gein toegepast op mijn database, en inderdaad had ik er ook een paar bit-veldjes in staan. Ik heb ze omgezet naar int, en het werkt nu wel...

Wel fraai trouwens dat je op deze 'oplossing' bent uitgekomen, want daar zou ik het toch niet zo snel in gezocht hebben. Je zou inderdaad gaan denken aan een Microsoft bugje!

We kunnen in ieder geval wat gerichter verder zoeken, want het lijkt er op, dat de zere plek hiermee gevonden is!

Michel

 

[linkav]

Antw

Beste Michel,

Mocht jij nog iets anders tegen komen, te weten komen, hoor ik het graag. We zijn al wel een stapje verder op deze manier..

Groetjes
Ariane

 

[OctaFish]

Hoe kwam je erbij om de Bit-velden om te zetten naar Int? Daar zou ik zelf niet zo snel aan hebben gedacht!

Michel

 

[OctaFish]

Het oorspronkelijke probleem leverde een foutmelding op m.b.t. het opslaan van een record. De oplossing van linkav is denk ik nu, na enig onderzoek, de enige juiste. De manier waarop SQL server Bit-data opslaat is namelijk anders dan Access:

SQL-server:
bit - Integer data with either a 1 or 0 value. If a number larger than one is used, it is converted to one.


Access:
Ja/Nee - Veld dat slechts een van twee waarden kan bevatten: (Ja/Nee, True/False, Aan/Uit). 1 bit.

In Access worden de waarden 0 en -1 opgeslagen. -1 levert dus een probleem op in SQL server, omdat alleen 0 (nul) en 1 worden geaccepteerd.

Dat de foutmelding die je op het formulier krijgt daar niets mee te maken heeft, is niet geheel onverwacht bij een Microsof produkt Het zegt ook wel iets over de manier waarop er bij M. wordt samengewerkt...

De enige oplossing is denk ik dus om in een SQL database geen bit-velden te gebruiken, als je er een Acces frontend voor hangt. Ik heb ondertussen alle bit-velden veranderd in Smallint, en alles werkt weer zoals het hoort.

 

[Linni]

Schrijfconflict

Ook ik heb nu last van een schrijfconflict. Zoals ik uit jullie eerdere post kan opmaken, is het een oplossing om de bit's in int's te veranderen. Maar hoe doe ik dat in de tabel? Bij datatype? Help!

 

[OctaFish]

Deze post is al een tijdje dicht, zoals je kunt zien.... Een forum kent een paar regels: een ervan is dat je geen vraag overneemt van iemand anders. En al helemaal niet als die vraag is een aantal jaar is opgelost... In dat geval begin je dus een nieuwe vraag. De kans dat iemand gaat helpen bij een opgeloste vraag is namelijk niet zo heel groot. In dit geval heb ik aan de SQL server kant een aantal eigenschappen van de velden aangepast. Dus de Bit velden omgezet naar Smallint.