passwoord module 32 bits werkt niet op 64bits....

  • Onderwerp starter Onderwerp starter jan62
  • Startdatum Startdatum

jan62

Gebruiker
Lid geworden
19 jan 2010
Berichten
81
k heb een vraagje over en database die ik ooit eens heb gemaakt in een 32bits uitvoering van Access deze database is voorzien van en wachtwoord en daarvoor gebruik ik een module in 32 bits. ik werk nu met een 64 bits uitvoering van access. Als ik nu opstart en gebruikersnaam en wachtwoord invul opent hij de module met de kreet dat ik hem moet aanpassen naar 64 bits. zie de foto met de melding. ik weet niet wat ik nu zou moeten veranderen. Of zit die module gewoon standaard in de 64 bits versie en moet ik die ervoor in de plaats nerzetten
 

Bijlagen

  • Schermafbeelding 2025-05-09 153618.png
    Schermafbeelding 2025-05-09 153618.png
    6,5 KB · Weergaven: 4
Laatst bewerkt:
Het heeft niets met de module te maken, en dat zegt de melding ook helemaal niet. Die zegt namelijk dat de code in het project moet worden aangepast. Er bestaat dus ook geen '64-bits module'. Alle modules zijn, kortom, versie onafhankelijk.

Wat wél een probleem is, dat sommige functies en procedures niet werken omdat de betreffende aanroepen anders moeten. Dat kan op een simpele manier, als je 100% zeker weet dat de database alleen op een t4-bits Office gebruikt wordt. Zijn er nog computers die op 32-bits Office draaien, die ook met deze database moeten werken, dan is het wat ingewikkelder. Eerst de simpele oplossing:
Gebruik de functie om de database te compileren om de 'fouten' in de database te vinden: je moet ze namelijk allemaal aanpassen. En als je één functie hebt, heb je er waarschijnlijk meer.

Heb je een foute functie gevonden, vervang dan de regel
Code:
Declare Sub
In
Code:
Declare PtrSafe Sub
Bij functies:
Code:
Declare Function
In
Code:
Declare PtrSafe Function

En hier de iets ingewikkelder variant, die op beide systemen werkt.
Code:
#If VBA7 Then
     Declare PtrSafe Sub...
#Else
     Declare Sub...
#EndIf
Uiteraard doe je hetzelfde met de functies, zoals hierboven is aangegeven.

Als je alles hebt aangepast, en bij het compileren geen foutmelding meer krijgt, heb je de database omgezet naar een 64-bits variant. Of een 32/64 bits variant.
 
ik had al een melding gezien dat o,a iets veranderd moest worden in Declare PtrSafe Function maar dacht als er een complete module is die 64 bits is vervang ik deze module daarvoor. Ik ga er mee aan de slag morgen eerst een Tourtocht fietsen van 100KM en erna genieten van kleinzoon die komt logeren. Zondag is het Access day.....................
 
Succes met het fietsen, en met de geplande computerdag!

als er een complete module is die 64 bits is vervang ik deze module daarvoor.
Helaas, dus. Een (nieuwe) module is gewoon een lege pagina die uit zichzelf niks doet. Een 32 bits database met 20 modules waar niks in staat werkt perfect in Access 64 bits. Zie modules als een schrift waarin je van alles opschrijft. Wát je opschrijft, bepaalt of het boek een roman is, of een telefoonboek :). En zo is dat ook met modules en code.

Succes met het fietsen, en met de geplande computerdag!
 
Goedemorgen, ondertussen weer even druk bezig geweest met Access hier. De Module aanpassen zoals door jou is omschreven werkt perfect, nu heb ik nog een vraag over als ik de database die ik gemaakt heb met een backend en een frontend is deze Drive afhankelijk. Kan ik deze optie ook weer verwijderen en er een gewone database van maken zonder die opties
 
Ik snap niet helemaal wat je bedoelt met 'drive afhankelijk'. Een BE wordt aan een FE gekoppeld, waarbij je uiteraard altijd moet aangeven wáár die BE staat. Dat pad is in beginsel een 'harde' verwijzing, maar die kun je best zodanig 'soft' maken dat je de hele constructie kunt verplaatsen zonder dat je de koppelingen kwijt raakt. Een alternatief is om de BE op een netwerkschijf te zetten die voor alle gebruikers dezelfde padverwijzing heeft.
Zo heb ik dat zelf altijd ingericht op het werk: de BE op het netwerk, en de FE bij de lokale gebruiker op de computer. En dat werkt dus zonder aanpassingen in de FE. De eerste variant die ik beschreef zet de BE in een (sub)map van de FE. Je gebruikt dan CurrentProject.Path als uitgangspunt voor de BE. En ook dan hoef je niet veel aan te passen.
Daarnaast gebruik ik een functie die bij het openen van een FE de connecties herstelt als de BE 'onvindbaar' is. Dat is ook nog een oplossing.

Om op de vraag zelf antwoord te geven: Om een FE weer een zelfstandige database te maken, hoef je niet veel meer te doen dan de gelinkte tabellen vanuit de BE te kopiëren naar de FE. Ze krijgen dan de eigen naam plus "_1" er achter. van Als je dat hebt gedaan, kun je de koppelingen verwijderen, en de namen van de vaste tabellen opschonen door de "_1" weg te halen. De database is dan weer een zelfstandige database, en werkt dan zonder koppelingen.

Als de database alleen voor jezelf is, en het probleem dus is dat je bij het verplaatsen naar een andere schijf of map de koppelingen kwijt bent, zou ik één van de drie opties gebruiken die ik hierboven heb beschreven.
 
Ik had het ook op die manier op een netwerkschijf staan zoals jij het omschrijft in het eerste stukje, het progje heeft jaren gefunctioneerd voor metingen aan producten voor ISO 2000 en is ondertussen vervangen voor en Professionele meetmachine. Doordat ik er thuis nog wel eens mee bezig ben en het wel eens verplaats naar en andere schijf wist ik niet meer hoe ik dat moest oplossen en dat is mij nu weer duidelijk geworden. Ook is mij duidelijk hoe ik er weer een database van maak zonder dat frontend en backend verhaal want dat heb ik thuis niet nodig.
 
Ik gebruik regelmatig USB sticks of externe SSD schijven waar ik Access programma's op heb die ik dan aansluit op een USB kastje met 7 poorten op mijn PC,. Dit doe ik omdat ik ook regelmatig op de laptop werk. vervelende is als ik dan een koppeling op mijn buroblad heb van een programma de schijfletter nog wel eens anders wil zijn als ik de stick of schijf aansluit, is hier mischien ook een truckje voor dit te voorkomen.
 
Terug
Bovenaan Onderaan