Zeer goede handleiding van octafish maar toch nog een vraagje

[conehead]

Hallo,

Ik heb de handleidingen van octafish doorgenomen van access maar het is me toch niet echt duidelijk hoe met records te werken in access, ze lezen lukt maar hoe koppel je nu juist code aan de knoppen om naar een volgend record te gaan na het inlezen van de record en hoe update je een record enz ... ga je naar de volgende enz..

Dus je start eerst met het inlezen van de velden:

Private Sub Form_Load()
Dim cnt As New ADODB.Connection
Dim rst As New ADODB.Recordset
Dim sTabel As String, sVelden As String
Dim arr As Variant
 sTabel = "tblContacts"
 Set cnt = CurrentProject.Connection
 Set rst = New ADODB.Recordset
 strSQL = "SELECT * FROM " & sTabel
 With rst
 Set .ActiveConnection = cnt
 .CursorType = adOpenKeyset
 .LockType = adLockOptimistic
 .Open "tblContacts"
 End With

Daarna koppel je een tekstbox aan de ingelezen velden en krijg je ze te zien op het scherm
maar hoe ga je nu verder
Ik dacht een nieuwe knop te maken en daar dan als actie in een sub rs.moveNext te plaatsen om naar een volgend record te gaan maar dit lukte niet ...

Dus ik doe duidelijk iets verkeerd ... En alle voorbeelden op internet wordt getoond met een mesagebox waar waarden worden uitgelezen maar dat is nu net iets anders dan in access zelf ...

Alvast bedankt

 

[OctaFish]

Dank voor je complimenten; altijd leuk om te lezen :thumb:
Maar dat gezegd hebbende, snap ik je vraag niet helemaal. Want je wekt de indruk alsof je een niet-afhankelijk formulier wilt bouwen dat je dan met een recordset koppelt. En de eerste vraag moet dan toch zijn: waarom? Want aan je code te zien doe je al een paar zaken dubbel (variabelen vullen en vervolgens niet gebruiken) en werk je gewoon met een tabel die al in de database zit. Dus de vraag is dan, waarom je daar een recordset aan wilt hangen en niet de tabel aan het formulier.

 

[conehead]

Mijn bedoeling is idd een bestaande tabel op een formulier weergeven en dan bladeren via next of move first enz ...
Of een formulier openen via een knop en starten in de weergave record toevoegen ...

Ik ben in de veronderstelling dat dit de manier van werken is als je alles in vba wenst te doen ... Vandaar dat na het lezen over je handleiding over recordsets ik dit aan het bekijken ben. Je sprak toen op het einde nog van een volgende cursus maar daar heb je wellicht nog geen tijd voor gehad aangezien ik die niet kan vinden.

Maar als ik het zo hoor doe jij dit ook niet zo en zie ik het dus verkeerd ?

 

[OctaFish]

Er zijn verschillende manieren van werken, en die zijn een beetje afhankelijk van je situatie. Hoe meer mensen er tegelijk in de database moeten, hoe meer moeite je moet doen om de db soepel te laten werken. Bij 3-5 mensen kun je bijvoorbeeld prima met één database werken, maar zijn dat er meer dan is een frontend-backend veel beter. En zijn het er nog meer (meer dan 30 of zo) dan is het werken met recordsets te overwegen. Idee er achter: hoe korter mensen iets in de database 'claimen', hoe beter de db werkt. En met onafhankelijke recordsets is de procestijd het kleinst. Zit iedereen tegelijk in dezelfde database, dan is de belasting het grootst. Dus dat moet je als overweging gebruiken.

Om op de vraag terug te komen: een formulier kun je op verschillende manieren openen. De standaardwijze is dus lezen+muteren, maar dat kun je dus aanpassen. Je kunt formulier dus met een knop in Alleen lezen modus zetten, Volledig bewerken of Alleen toevoegen. Wat jij wilt. Bladerknoppen kun je prima met de wizard maken. Dat werkt prima. Hoef je zelf niks voor te verzinnen.

 

[conehead]

Alvast bedankt voor de uitleg en die knoppen had ik idd al werkend op een andere manier maar nu weet ik alvast dat ik het niet moeilijker moet maken dan nodig.

In mijn geval voor een 4tal gebruikers zijn die recordsets dan eigenlijk niet nodig.

Was wel al bezig met het maken van 2 frontends omdat bepaalde gebruikers niet veel moeten kunnen.

groetjes

 

[OctaFish]

Microsoft zelf zegt dat je met 5-10 gebruikers makkelijk in een Acces database kan werken. De praktijkmensen zeggen: hoe minder, hoe beter . Ik zou inderdaad met 4 mensen al kiezen voor een FE-BE oplossing waarbij elke gebruiker een eigen frontend krijgt. Op die manier zitten ze elkaar het minst in de weg. Ik zou overigens wel 1 FE maken en 1 BE (dat laatste is logisch) en op basis van een rechtentabel bepalen wie wat mag doen/zien. Dat scheelt een hoop werk, en zeker i.v.m. onderhoud is het veel beter om maar één FE te hoeven onderhouden en uit te rollen.