records niet meer te bewerken

Status
Niet open voor verdere reacties.
S

scw

Gebruiker
Lid geworden
5 jun 2009
Berichten
530
Beste forumleden,

Ik zit met de volgende situatie:

Ik heb mijn Access bestand op de server staan (geen BE-FE). Lokaal heb ik een snelkoppeling gemaakt naar het bestand op de server.

Wanneer er een gebruiker in het bestand zit, formulier maakt niet uit (en openlaat staan vooral, geminimaliseerd bijv.), kan de andere géén enkele andere willekeurige record bewerken. Zodra dat wordt geprobeerd verschijnt de melding "de actie Save is geannuleerd".

Nog belangrijk is dat ik in mijn opties, tabblad geavanceerd, aangevinkt heb staan:
Standaardrecordvergrendeling: bewerkte record en databases openen met recordvergrendeling.

Mijn vraag is: hoe kan ik deze melding voorkomen en bovenal het zou toch mogelijk moeten zijn als iemand het hoofdformulier open laat staan, een ander een record kan wijzigen. Ik ben al van plan om mijn DB te splitsen, maar ben benieuwd of dit het desbetreffende probleem ook oplost??

Ben benieuwd naar een oplossing! Alvast bedankt!
 
Je kunt een Timer actie op je (hoofd)formulieren zetten, waarbij na een x-aantal minuten het formulier bijvoorbeeld gesloten wordt. Je kunt de Timer actie bijvoorbeeld koppelen aan het MouseMove event.
 
Dank voor je oplossing Michel,

Op zich vind ik het wel jammer om deze oplossing te gebruiken: het is toch ook wel erg gebruiksvriendelijk is om de applicatie open te laten staan (dat betekent dat het in ieder geval wordt (dagelijks) gebruikt wordt!). Ik verwacht dat de gebruikers het niet zullen waarderen wanneer er automatisch afgesloten wordt (verbazing, irritatie).

Zijn er nog andere wegen die naar Rome leiden? Het zou fraai zijn als er echt met meerdere gebruikers tegelijkertijd in gewerkt kan worden?!
 
voortgang...

Ondertussen heb ik eens getest of mijn probleem opgelost zou worden met het splitsen van de DB in BE-FE. Helaas verhielp dit het probleem niet...:(

Mogelijk zal ik de menustructuur van mijn DB moeten aanpassen: nu wordt altijd standaard een hoofdscherm geopend waar al verschillende subformulieren op staan met gegevens uit verschillende tabellen. Ik denk wanneer ik een hoofdmenu creeër welke geen gebruik maakt van tabellen erop, dat dit misschien voorkomt dat gebruikers niet kunnen bijwerken zodra iemand de DB geopend heeft laten staan... ???
 
Dat zou al een hoop schelen; juist het feit dat je formulieren open hebt die aan een tabel zijn gekoppeld, levert je problemen op.
Een (arbeidsintensieve) oplossing zou nog kunnen zijn, om alle formulieren niet-gebonden te maken, en met behulp van VBA Recordsets te maken waarmee je de databasebewerkingen kunt uitvoeren.
Je maakt dan een niet-gebonden formulier, dat je vervolgens via een Recordset vult met gegevens, waarna je de recordset sluit. Als de gebruiker vervolgens bewerkingen uitvoert, zoals een nieuw record aanmaken, of muteren, laat je die handeling weer met een recordset uitvoeren.
Op die manier belast je de records alleen als er daadwerkelijk iets moet gebeuren.
Zoals gezegd, 't is wel wat werk....
Overigens ben ik het niet helemaal met je eens dat een geopend formulier onbeperkt door een gebruiker geopend moet kunnen blijven. Ik vind, dat je na pakweg 10 minuten inactiviteit best een formulier mag sluiten. Moeten ze maar niet in slaap vallen ;)
 
Ah! Bedankt voor deze suggestie met de Recordsets, ik voel er zeker wat voor. Ik denk gezien de achterliggende gedachte van mijn DB het de enige juiste oplossing is. Het zal vrees ik inderdaad gecompliceerd werk zijn, maar ik ga proberen om er uit te komen met wat zoekwerk op internet over Recordset.

Enig idee ook wat voor (negatief) effect het zal hebben op de snelheid van de DB? Heb je toevallig een DB in je bezit die al gebruik maakt van Recordset voor opvragen tabel? Zodat ik alvast een sample heb of code...

Dank je wel nogmaals!:thumb:
 
Zelf ben ik ook nog volop aan het leren met deze materie. Ik heb wel een voorbeeldje, dat je kunt bestuderen. Overigens hoef je niet bang te zijn voor nadelige effecten; je systeem wordt er zelfs sneller door. Is ook één van de redenen dat ik ook er naar wil streven om op deze manier mijn databases te maken.
Ik zoek vanavond wel een passend voorbeeld op.
 
In dit voorbeeld zitten 2 formulieren, die alletwee via recordsets worden gevuld.
Het eerste formulier heeft een 'live' link met de tabel, en wordt dus direct gevoed en bijgewerkt. Het tweede voorbeeld leest de recordsource bij laden, verbreekt vervolgens de verbinding en update de tabel pas bij een klik op de knop.
De laatste variant geeft dus de meeste vrijheid qua recordset, maar draagt wel als risico dat verschillende mensen in hun eigen kopie van de recordset muteren, waardoor je verschillende versies kunt krijgen.
Bekijk ze maar eens goed.... Er gebeurt van alles ;)
 

Bijlagen

  • Bound en Unbound Forms.rar
    40,1 KB · Weergaven: 41
Een Frontend-Backend is denk ik altijd wel aan te bevelen met meerdere gebruikers. Ik zou dat dan ook zeker nog een keer overwegen.
Hierbij een voorbeeldje met een FE-BE oplossing met ongebonden formulieren die de records ophalen m.b.v. VBA en recordsets.
Eén formulier met een actieve link naar de BE, het andere formulier werkt met een lokale recordset.
 

Bijlagen

  • FrontEnd-BackEnd.rar
    64,3 KB · Weergaven: 29
@Tardis: bedankt voor de link: vind het een zeer interessante site, er staat veel op! Goede tips!

@OctaFish: hartelijk dank voor de voorbeelden. Ik zie in beide DB's dat er gebruikt wordt gemaakt van modules. Ik probeer het gebruik van modules te vermijden (alles hardcoden), dus zodra ik er mee aan de slag ga, zal ik proberen of ik die module direct in de gebeurtenis vba kan plakken... even kijken of dat gaat.
 
Je kunt de code zonder meer op de formulieren gebruiken, zo is het in eerste instantie zelfs ook gemaakt.
De reden om er zoveel mogelijk functies van te maken is eigenlijk heel simpel: voor het openen van een tabel gebruik je in wezen steeds eenzelfde constructie: recordset defiieren, recordpointer opties instellen en de recordset openen.
Door er een module van te maken, hoef je alleen maar de module aan te roepen met de naam van de tabel, en klaar ben je...
Zoals gezegd: je kunt alles naar het formulier halen, en steeds opnieuw herhalen/uitvoeren, geen probleem!
 
toegepast

Goedemorgen Michel,

Gisteren heb ik lekker besteed aan het proberen onafhankelijk te maken van de velden. Ik lijk alles goed te doen, maar ik zal toch nog iets vergeten zijn: de velden populeren zich niet vanzelf, de velden blijven leeg. Desalniettemin krijg ik geen foutmelding. Inderdaad kon ik het gewoon vanuit de module overnemen.

Voor het gemak heb ik even mijn gestripte DB als bijlage hier. Hopelijk kun je vinden wat ik nu precies vergeet!

Groetjes SCW
 

Bijlagen

  • Unbound forms DB.zip
    96,9 KB · Weergaven: 36
Ik zie inderdaad wel een paar dingetjes...
Om te beginnen leg je een koppeling met een andere database die je niet hebt meegeleverd; de tabel die je opent zit er overigens wel bij. Ik neem aan, dat de constructie bij jou wel zal kloppen.
Verder heb je het subformulier op een tabelement gezet; ik weet niet of dat direct nodig is, maar persoonlijk zou ik dat niet doen. Tenzij je anders in de knoop gaat komen met de ruimte.
Ik krijg de bestaande info overigens wel op het subformulier te zien, maar toevoegen lukt inderdaad niet. Dat komt denk ik doordat het subformulier aan een tabel is gekoppeld. Ik zou dat dus niet doen, en de recordset opbouwen met VBA.
Ook snap ik niet helemaal wat de bedoeling is van al die aparte recordsets die je opent bij het opslaan; de routine loopt bij mij vast op het Outlook verhaal, maar ik vermoed dat er al eerder wat problemen zitten.
Als je het formulier vult met gegevens die je met een Recordset ophaalt,,dan kun je het opslaan ook het beste doen via Recordsets. Bij een ongebonden Recordset kun je met AddNew een nieuw record aanmaken, waarna je met rs.UpdateBatch de records toevoegt.

Nu heb je er een tabel achterhangen, en doet het Savecommando dus niet zo bijster veel..
Ik zou daar dus eerst naar kijken.
Tis niet iets wat ik zo even snel oplos, dus daar moet ik vanavond wat dieper in duiken...
 
Hoi Michel,

Inderdaad heb ik die koppeling nog niet goed denk ik: ik dacht omdat ik het voorbeeldbestandje ook werkte met deze path, terwijl het bestand zelf toch een andere naam had? Daarom had ik het alleen veranderd naar MonitoringTool.mdb, maar ik zal nog wel een directory goed moet zetten ofzo? De tabel is wel goed ingesteld idd.

Functioneel gezien is het voor mijn DB wel erg noodzakelijk, dat ik het op een tab kan houden. Ik moest het bestand helemaal strippen om te plaatsen (100kb), maar normaliter zitten er nog vier tabbladen naast.

Opmerkelijk, dat jij wel de info op het subformulier te zien krijgt: bij mij verschijnt wel de record maar de velden zelf blijven blance :confused::confused::confused:

Maar goed, ik ben reuze benieuwd als je er vanavond bent ingedoken!!


Thnx!!
 
vervolg

Ha Michel,

Was je ondertussen nog iets verder gekomen met het populeren van de velden?? Ik ben even benieuwd!

Thnx!
 
Ik had vandaag een introductiedag, dus geen pc aangeraakt vandaag... (kan ik iedereen aanbevelen ;) )
Kijk er morgen wel naar, want ben er wel mee bezig geweest.
 
@Octafish:

He Michel, ben je al een stukje verder gekomen? Ik ben nieuwsgierig ;)
 
Zal het weer eens bekijken! Ik denk wel dat ik 'm redelijk werkend heb, maar staat uiteraard thuis op de pc. :confused:
 
:) Ha Michel, ik verwacht niet dat je op dit moment thuis zit (waar je het bestand hebt), maar vroeg me af of ik misschien eens met jou versie kan gaan testen, zodra je de mogelijkheid hem toe te sturen?

M'n DB groeit in populariteit qua aantal gebruikers :cool:, en daarom is het jammer als ze teleur worden gesteld door een beperking als deze: dat ze niet kunnen bewerken terwijl er een ander in zit :( Vandaar heb ik dit puntje hoog op m'n prioriteitenlijst!

Thnx!
SCW
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan