#FOUT in goedwerkende dB (versie 2000) in Runtime 2010

Status
Niet open voor verdere reacties.

Johgs

Gebruiker
Lid geworden
19 mei 2011
Berichten
340
Ik heb een dB waarin een bepaald onderdeel al jaren goed werkt zonder ooit een foutmelding te geven.
Nu zijn we aan het migreren van WinXP naar Win7 en stuit ik op een merkwaardige foutmelding.
De dB is opgezet in een Office 2000 versie maar wordt onderhouden en draait onder Access 2003 (als 2000 versie). Na de migratie hebben we tevens Office 2010 gekregen maar werkgever (gezien WinXP makkelijk te raden welke) heeft er voor gekozen Access 2010 niet standaard beschikbaar te stellen (licentiekosten). Gebruikers werken nu met de dB via de runtime versie van Access 2010. Op zich werkt dit prima, ziet er net wat gelikter uit (afgeronde hoekjes e.d.) en zowaar nog een stuk sneller ook.

Er is echter één probleem. Werkend in de runtime opgeving is er één rapport, op zich een vrij simpel rapport, dat van een groot aantal waarden een gemiddeld percentage uitrekent, op zich wel een lange vloek van een formule (uit mijn begintijd, nog alle veldjes optellen en delen enz) maar correct werkend en snel.
De uitkomst is nu echter #Fout.

Start ik de dB op in Access 2003 (wel omslachtig, is beschikbaar via Citrix receiver) werkt het correct.

Gebruikers via Access 2003 laten werken is ook geen optie, in de Citrix receiver geen koppeling met Outlook (vanuit de dB kan o.a. het betreffende rapport verzonden worden) en een drama met printen.

In de runtime heb ik uiteraard geen enkele mogelijkheid om te gaan zoeken waar de fout vandaan kan komen en in Access 2003 werkt alles correct.

Iemand enig idee waarin die runtime zich kan verslikken?


Eén van de formules:
=Som(((Abs([1-1-KH]+[1-2-KH]+[1-3-KH]+[1-4-KH]+[1-5-KH]+[1-6-KH]+[1-7-KH]+[1-8-KH]+[1-9-KH]+[1-10-KH]+[1-11-KH]+[1-12-KH]+[1-13-KH]+[1-14-KH]+[1-15-KH]+[1-16-KH]+[1-17-KH]+[1-18-KH]+[1-19-KH]+[1-20-KH]+[1-21-KH]+[1-22-KH]+[1-23-KH]+[1-24-KH]+[1-25-KH]))+(Abs([2-1-KH]+[2-2-KH]+[2-3-KH]+[2-4-KH]+[2-5-KH]+[2-6-KH]+[2-7-KH]+[2-8-KH]+[2-9-KH]+[2-10-KH]+[2-11-KH]+[2-12-KH]+[2-13-KH]+[2-14-KH]+[2-15-KH]+[2-16-KH]+[2-17-KH]+[2-18-KH]+[2-19-KH]+[2-20-KH]+[2-21-KH]+[2-22-KH]+[2-23-KH]+[2-24-KH]+[2-25-KH])))/([Aantal_batch_1]+[aantal_batch_2]))/[aantal controledagen]

Lijkt erg verwarrend maar zit logisch in elkaar, basis is een formulier met 25 regels van 2 x 4 vinkveldjes, als er een vinkje geplaatst wordt worden de onderliggende 1 'tjes opgeteld (van 2x1 kolom) en gemiddelde bepaald over een bepaalde periode. De batch is omdat ipv 25 regels er ook gewerkt wordt met maar 20 regels.
 
Je probleem heeft vermoedelijk niks met je formule te maken (hoe veel makkelijker dat ook zou kunnen) maar waarschijnlijk met een fout in je VBA code waar de runtime over struikelt. Voordat je een runtime maakt van een 2003 db (totaal geen winst om een 2000 db niet te converteren naar 2003 in A2003) moet je de db eers inlezen in 2010 en goed compileren.
Als daar geen fouten uit rollen, kun je een runtime bestand maken.
 
Nou, ik heb de runtime niet gemaakt. Het is gewoon de 2000 versie die bij aanklikken (na enige installatie) opent in een omgeving die zichzelf runtime 2010 noemt. En helaas geen 2010 Access beschikbaar.
Die conversie gaat er overigens aankomen, denk dat de 2000 versie nu wel overal weg is. Vandaag al even getest, leverde vreemd genoeg 2 exemplaren op, de ene iets van 24 Mb en eentje van 16, kennelijk werd er na conversie nog even een opgeschoonde versie gemaakt.

in dezelfde dB zit overigens ook een grafische weergave gebaseerd op dezelfde gegevens, daar gebruik ik een query waarin o.a. dezelfde 50 velden uit de record in een expressie worden opgetelt, die bleek prima als basis voor een totaalquery die het gemiddelde weergeeft, al een stuk simpeler, maar een eenvoudigere manier om 50 velden uit één record op te tellen dan inderdaad optellen, heb ik nog niet gevonden, maar houdt me zeker aanbevolen voor tips.
 
Laatst bewerkt:
... heeft er voor gekozen Access 2010 niet standaard beschikbaar te stellen (licentiekosten). Gebruikers werken nu met de dB via de runtime versie van Access 2010.
Er zijn dus wel degelijk gebruikers met een normale Access versie. Jullie aanpak levert problemen op, en dat verbaast mij dus helemaal niets. Je moet toch echt minstens één pc hebben met een normale Access versie er op om a) te kunnen ontwikkelen en b) om de db te kunnen compileren. Want daar zit toch echt een probleem. Je kunt niet zomaar een 2000 db in een runtime van 2010 zetten en verwachten dat alles gelijk maar werkt. Al was het maar omdat je in de oude versie wellicht ergens een Datumcontrol hebt gebruikt die in 2007 is afgeschaft. Vervangen door een DatePicker. En dat moet je toch echt aanpassen in de code. En wellicht wordt er nog hard naar een bibliotheek verwezen waarvan het nummer ook is veranderd. Allemaal zaken die gecontroleerd moeten (kunnen) worden.
 
Ik zal eens uitvogelen of Access 2010 inderdaad leverbaar is maar onze ICT is zelf op Oracle over en bij problemen wijzen ze heel snel hulp af als het niet standaard is.
Gelukkig is genoemd probleem tot nu toe het enige en heb ik daar een oplossing voor paraat.

Alle VBA code in de dB is overigens nog steeds door Access zelf aangemaakt, daar zit geen eigen code in.


PS Er is wel standaard een openoffice variant beschikbaar, niet OpenOffice zelf maar..... Kan het zijn dat de dB daarin opent alsof het een runtime versie is?
 
Alle VBA code in de dB is overigens nog steeds door Access zelf aangemaakt, daar zit geen eigen code in.
Bedoel je dat jullie db door Microsoft zelf is gebouwd? Dan is er dus wel degelijk geld in huis :D. Access bouwt uiteraard zelf geen code, hooguit kun je met de wizard allerlei knoppen laten maken waar dan een macro achter hangt. Maar dan nog: die code moet gecheckt worden op het moment dat je de db converteert naar een nieuwe versie. Waarschijnlijk veel te laat voor jullie, maar heb je deze tool al eens op je documenten losgelaten?
 
Nee en helaas mogen we zelf niets installeren.
Maar ik bedoelde inderdaad dat ik zelf geen VBA schreef via de editor, afgezien van wat kleine wijzigingen van namen.
En geld, wat denk je dat die verlengde XP ondersteuning heeft gekost! ;-)
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan