OS-probleem m.b.t. Access

[Stefke]

Ik heb een vreemd probleem m.b.t. Access: op een windows 2003 server systeem waar een aantal mensen via RDP werkt in een accessdatabase is van de ene op de andere dag iets veranderd:

Als ik velden in de tabel al een format meegeef (bijv. “>” om hoofdletters te forceren) dan wordt de inhoud van het betreffende veld niet meer weergegeven in een keuzelijst (zonder invoekvak).
Als ik een query maak met daarin hetzelfde veld met “format(veld,”>”)” werkt het wel.

Het probleem doet zich voor in oude database (waar het nooit een probleem was) maar ook als ik even snel een testdatabase maak.
Het is geen accessprobleem, want op andere computers werkt dezelfde database mét de tabelformats probleemloos, vandaar dat ik het in “OSen” zet. Ook de testdatabase werkt daar zonder euvels.

De beheerder van het betreffende netwerk (of eigenlijk: server) heeft aangegeven dat er geen updates of aanpassingen zijn verricht rond de datum waarop het probleem zich voor ging doen. Ik heb een vaag idee dat het misschien iets met regionale settings te maken heeft maar die staan goed (nederlands) op het eerste oog.

Iemand een idee? Ik kan het oplossen door alle formats in de queries te verwerken, maar dat is niet de bedoeling (dat is geen oplossing voor het probleem zelf, alleen een lapmiddel) omdat hetzelfde programma in meer omgevingen gebruikt wordt.

[alt-92]

Een 2003 Server is geen client OS, dus ik verplaats het topic naar Windows Servers en Server-software

Denk dat het daar sowieso wat beter op z'n plaats is.

[Stefke]

Heeft toevallig iemand een idee? Het probleem bestaat nog steeds en ik heb het nog niet kunnen oplossen.

Inmiddels ben ik er achter dat het definitief alléén bestaat op de betreffende server (en alle ingelogde sessies), op geen enkele andere omgeving gedragen mijn databases zich op deze manier.

Officerepair door de supportafdeling heeft niet geholpen

[ Voor 57% gewijzigd door Stefke op 20-11-2007 20:51 ]

[elevator]

Ik ga je topic verplaatsen naar het Officesuites en -software forum aangezien je hier weinig reacties krijgt en het ongeveer net zo veel raakvlakken heeft met Officesuites en -software als met Windows Servers en Server-software

Windows Servers en Server-software >> Officesuites en -software

[Stefke]

Nog steeds niks? Niemand een idee wat hier de oorzaak van zou kunnen zijn?

Om het makkelijker te maken, ik heb er nu ook op mijn eigen server (Vista Ultimate) last van... Geen idee sinds wanneer, ik zag het vandaag toen ik een database opstartte via RDP op de server (db opstarten doe ik normaal niet op de server zelf, maar op mijn desktop).
Er staat me heeel vaag iets bij dat ik laatst al iets gezien had hiervan (op mijn server dus) maar dan heb ik er toen in ieder geval niet bij stilgestaan (wat ik op zich vreemd zou vinden als het inderdaad ook daar optrad en ik er niks van dacht).

Dus: geen veldformat (op tabelniveau) meer in keuzelijsten, en geen enkel idee sinds wanneer, en nu dus op 2 totaal verschillende omgevingen.
Als ik dezelfde database vanaf een andere computer via het netwerk opstart heb ik (nog) geen probleem.

[ Voor 9% gewijzigd door Stefke op 26-11-2007 15:44 ]

[Lustucru]

Heb je gechecked of het probleem ook optreedt als je niet via RDP werkt maar lokaal interactief?

[Stefke]

Hmm...das een goeie. Op de server bij mijn klant is het alleen via RDP mogelijk, maar bij mij zelf moet ik even uitproberen, maar ik werk op mijn eigen server via logmein.com. Dat neemt via een httpstunnel over en is iets compleets anders dan RDP, en ook daarmee heb ik het

Toch even proberen echt lokaal op mijn eigen server.

edit: ja, dan ook. Had het probleem zowieso eerst niet (ook niet met RDP)

[ Voor 10% gewijzigd door Stefke op 26-11-2007 16:36 ]

[Stefke]

Inmiddels heb ik dit probleem ook al een hele tijd op mijn eigen (Vista) server. Op zich niet zo erg, ik installeer die binnenkort opnieuw en verwacht dat het probleem dan opgelost is (maar zeker weet ik dus niet)

Helaas heb ik het, volgens mij sinds vandaag, ook bij een andere klant. Het LIJKT erop dat het gebeurd is nadat ik een bepaalde record in een tabel (met maar 1 record) wilde bewerken, daarbij de melding kreeg dat de record in gebruik was ("overschrijven of wijzigingen negeren?").
Ik heb voor opslaan gekozen, maar daarna was de record (tabel bestaat uit 1 record) naar de klote: sommige velden hadden onleesbare tekens, andere hadden min of meer willekeurige waarden gekregen die nergens op slaan, sommige velden waren leeg.

Nu weet ik vrijwel zeker dat dit probleem niet eerder op dat netwerk voorgekomen is, en nu heb ik hetzelfde probleem: in keuzelijsten worden formats niet meer weergegeven (zie boven).

Er staat mij bij dat ik dit probleem (record in gebruik, toch opslaan, daarna compleet verneukt) ook bij die eerste klant (zie boven) gehad heb, alleen weet/wist ik daar niet meer of dit ook ongeveer hetzelfde moment was als waarop dit probleem met formatweergave in keuzelijsten optrad.


Dit is echt strontvervelend . Het lijkt zich wel te verspreiden langzaam, terwijl ik niet weet wat de oorzaak/oplossing is.

Op mijn eigen computer heb ik volgens mij dit effect (de verneukte record) niet gehad, wel heb ik daar het probleem.


Om een idee te geven, deze record:
tijdbackup 0:30
shutdown ONWAAR
shutdown_user
tijd_shutdown 0:03:00
countdown 0:02:42
tijd_down 0:10:00
reden van shutdown Onderhoud aan de database
PadNaarDatabase P:\PLANNING_ACCESS\PCE_backend.mdb
Verw_Hist_mndn 36
Autoplan_reserve_marge 2
Autoplan_overcapaciteit WAAR
Autoplan_min_uren 3
logintimer 60000
tijd_refresh_screen 1

is gewijzigd in:
tijdbackup 0:00
shutdown Yes
shutdown_user
tijd_shutdown 0:00:00
countdown 0:00:00
tijd_down 0:00:00
reden van shutdown @
PadNaarDatabase 搠瑡扡獡･僾尺䱐乁䥎䝎䅟䍃卅屓䍐彅慢
Verw_Hist_mndn 191
Autoplan_reserve_marge 1,47E+13
Autoplan_overcapaciteit Yes
Autoplan_min_uren 1,041667
logintimer 18
tijd_refresh_screen 64

(Ja, chinese tekens... )

[MAX3400]

Volgens mij heb je een probleem met unicode, regional settings en je installed languages ten opzichte van de keyboardinstellingen van de clients en/of bepaalde velden in je database.

[Stefke]

Ja, gezien die chinese tekens zou ik dat ook gaan denken (heb er al eerder aan gedcht dat het wellicht iets in regionale settings is), mar alles staat op Nederlands... Ik zou niet weten waar ik nog meer moet kijken.
Maar hoe zit het met de getallen? Daar is toch geen lijn in te trekken? (als het een of andere conversie zou zijn)


Ik moet nog uittesten of het opgelost is als ik de database waar deze tabel in staat vervang door een backup, maar dat kan momenteel niet, en ik vermoed dat dat het probleem van de niet weergegeven formats niet oplost.


Let op: het probleem is niet zozeer deze record en de verneukte gegevens, die kan ik gewoon vervangen met nieuwe gegevens, het gaat erom dat geen formats worden weergegeven in velden in keuzelijsten, dus als ik een boolean converteert naar een "X" (true) en " " (false) dan zie je alleen nog maar een leeg veld.

[ Voor 66% gewijzigd door Stefke op 13-01-2008 12:42 ]

[Verwijderd]

Ik denk da het met de onderliggende database engine/server te maken heeft.
De koppelingen tussen Access en deze zitten in de MDAC implementatie.
Check eens of de versie op de afwijkende systemen anders is.

By MS kun je ook tools voor het controleren van die MDAC vinden.
Het is al enige tijd terug voor mij maar http://www.microsoft.com/mdac was het path.

Een soortgelijk probleem heb ik zo'n 5 a 6 jaar terug ook gehad en toen was de
ondersteuning van DAO het probleem.

Even gecheckt:
http://msdn2.microsoft.com/en-us/data/aa937730.aspx
MDAC Utility: Component Checker

[ Voor 9% gewijzigd door Verwijderd op 13-01-2008 12:57 ]

[Stefke]

Heb m, maar wat moet ik er precies mee doen? Als ik de optie "perform machine analysis and automatically determine the release version" krijg ik een "unknown".


Als ik vanuit VBA via Access naar de koppelingen kijk staan ze goed ingesteld. (geen foutmeldingen).

Wel zitten er verschillen tussen de diverse systemen (bijv. mijn Vistaserver en de klantenomgeveing) in de gebruikte verwijzingen, maar dat heeft nog niet voor problemen gezorgd (niet dit probleem in ieder geval)

[Verwijderd]

Zoals ik al zei is het lang geleden.
Ik werk intussen niet meer met windows maar linux en heb dus geen ms-office geinstaleerd staan,
of ms-access als stand alone.

Heb m, maar wat moet ik er precies mee doen? Als ik de optie "perform machine analysis and automatically determine the release version" krijg ik een "unknown".

Dit zou eigenlijk al een error zijn. Hij moet als alles goed is wel degelijk de version kunnen
bepalen of er wordt iets gemist in de installatie.

Wel zitten er verschillen tussen de diverse systemen (bijv. mijn Vistaserver en de klantenomgeveing) in de gebruikte verwijzingen, maar dat heeft nog niet voor problemen gezorgd (niet dit probleem in ieder geval)

Zijn die verschillen te koppelen aan de foute systemen.
Ik bedoel dus of de verschillen van de foute systemen t.o.v. goede. De gegevens van de foute gelijk en van de goede ook gelijk maar verschillend tussen goede en foute?

Er staat me ook nog iets bij van 'colocation' property van de tabellen, die moeten ook gelijk zijn.
Deze was, uit diep geheugen, iets van '039' of '033' toen bij mij.

Waar ik aan denk is dat tussen de oude systemen en de nieuwe geinstaleerde er een verschil zit in
de syntax van de SQL verwerking.
Iets wat dat stiekum update naar nieuwere versie die dus niet beschikbaar is na een verse install.
System updates en/of update naar IE7 (daar zit MDAC ook in).

Als ik velden in de tabel al een format meegeef (bijv. “>” om hoofdletters te forceren) dan wordt de inhoud van het betreffende veld niet meer weergegeven in een keuzelijst (zonder invoekvak).
Als ik een query maak met daarin hetzelfde veld met “format(veld,”>”)” werkt het wel.

Uit je OP. De laatste regel is ook de juiste methode volgens mij.
Dat de voorgaande methode werkte, door bug of iets dergelijks, is dan toen mooi meegenomen maar je zou eigenlijk die informatie al in uppercase er in gezet moeten hebben.

Ik ken deze “format(veld,”>”)” constructie nog niet, met name de '>', al snap ik hem wel.
Kun je ter verduideling hier je query eens laten zien. De oude en die nieuwe werkende.
Ik weet n.l. ook niet hoe je _de tabel al een format meegeef (bijv. “>” om hoofdletters te forceren) _ doet, ben dus er al lang uit


Volgens mij zit het probleem in de tussenlaag tussen ms-access en de data op het systeem(server).

Dat de beheerder van het betreffende netwerk aangeeft dat er rond die datum geen updates zijn geweest zegt niets. Trouwens 'rond' kan al niet want dat betekend ook NA die datum
Een update kan al 4maanden op een systeem zitten maar als de (speciale) functie pas 4 maanden later eens gebruikt wordt pas boven tafel komt.
Het gaat dus om iedere updates tussen het aanmaken van programma/data en de datum van konstatering.
En dat is nu juist het ondoorzichtige bij MS. Ze doen updates voor A en nemen stiekum B mee binnen A, Nooit een echte changelog.

Lees over MDAC ook eventueel http://en.wikipedia.org/w...ft_Data_Access_Components
met name de History. De vermelding van undocumented change MDAC 2.7 (InfoWorld) is daar in terug te vinden.

Windows DAC 6.0
Windows Vista will no longer use MDAC, but instead use Windows DAC, which consists of updated versions of ADO, OLE DB, and ODBC components. According to Microsoft, "Windows DAC includes some changes to work with Windows Vista, but is almost entirely functionally equivalent to MDAC 2.8."

Shure, almost.....

[ Voor 8% gewijzigd door Verwijderd op 13-01-2008 14:48 ]

[Stefke]

Bedankt voor je reactie, ik ga nog eens e.e.a. bestuderen.

Format instellen in tabellen: dat is gewoon te doen in de eigenschappen van een veld, standaardfunctie van Access.


edit: nog even iets: ik merk nu ineens dat onder Access op mijn Vistaserver de toetsenbordindeling niet goed is (@-_+= etc). Echter alléén onder Access...
Onder Excel, word, Windows, IE etc is de toetsenbordindeling wel goed.

Heb het bij mijn klant gechecked, daar is wel onder alle omstandigheden het toetsenbord goed ingesteld, dus dat lijkt ook niet de oorzaak, alleen: waar moet ik dat fixen op mijn eigen computer?? Ben nieuwe functionaliteit aan t maken, mar t typt zo niet erg handig.

[ Voor 83% gewijzigd door Stefke op 13-01-2008 16:02 ]

[Verwijderd]

Geen idee waar dat in te stellen is.

Heb nog wat verder gepuzzeld. en had al wat ingetikt.
Voor het posten toch nog eerst even een check voor andere reacties.

Ik ken deze “format(veld,”>”)” constructie nog niet, met name de '>', al snap ik hem wel.
Kun je ter verduideling hier je query eens laten zien. De oude en die nieuwe werkende.
Ik weet n.l. ook niet hoe je _de tabel al een format meegeef (bijv. “>” om hoofdletters te forceren) _ doet, ben dus er al lang uit

OK denk dat ik weer wat meer weet.

Laatste punt in quote:
Dat wegbergen in hoofdletters doe je dus ws in de veld properties in de grafische omgeving.
Staat me nu bij dat daar een regel met format was en die is voor invoer in de tabel.
*** bevestigd dus****

Dit is/was dan wel in de table design mode.
Kan het zijn dat er format characters ('>') vervangen zijn door andere?
Staat mij bij dat 'A' hoofd en 'a' kleine was.
Weet echter niet meer wat de 1 of meerdere aanduiding was.
Ik zou eens controleren of de format methode tussen de systemen verschild.

En dat MS _daar_ wat in veranderd heeft dat weet ik nog zeker wel, nooit meer gebruikt die formating methode met table design. (DAO/ADO en backend server changes toen 2000)

Toch nog even een ander punt:

Het lastige is volgens mij dat MS-Access een beetje ondoorzichtig is.
Het wordt samen met de tabellen als 1 geheel gezien terwijl het dat niet is.

Je hebt de userinterface als MS-Access en de toepasing als applcatie.mdb file.
Deze mdb file is je werkelijke applicatie en kan al dan niet tabellen bevatten.

Je format() is in de mdb met de tabel opgeslagen. Is de tabel echter via b.v. ODBC dan
is de format in de applicatie mdb opgeslagen.
Zou je MySQL gebruiken dan kent die de ms formating niet eens.

De executable userinterface gebruikt de tabel properties uit de applicatie.mdb
om de interne tabel of externe tabel properties van de table.mdb.
Het zorgt dus voor de interactie tussen applicatie en data.

Heb je een table.mdb dan zijn die table eigenschappen, je format b.v, voor alle aplicatie.mdb gelijk.
Andere methode voor opslag/access van de tabel, kan dus MSSQL, SQL200x of ander
backend, hebben niet automagisch ook die tabel properties.

Het mag/kan m...nken lijken maar juist dit opsplitsen in de echte onderdelen
helpt het bepalen waar nu eigenlijk het probleem zit.

Zoals je dus nu kunt begrijpen is de infrastructuur van het hele project belangrijk.
Hoe is je data access, DAO, ADO, ODBC, MSSQL, SQL200x, etc? (backend access)
Wat is de data server, MS-ODBC, unix-odbc, MSSQL, SQL200x, MySQL, etc? (backend server)
Versies en al dan niet upgrades uitgevoerd kunnen invloed hebben.

Uit je post valt nog wel af te leiden dat je een losse aplicatie.mdb hebt maar
niet of je een tables.mdb of andere data opslag hebt.

Het is dus niet gegarandeerd dat in table properties een format opgeven altijd werkt
op de data backend. Het kan zelfs verloren gaan bij incorrect copieren tussen 2 mdb files.
Over verschillen in MDAC versies en WDAC nog maar te zwijgen.

Ik werkte vroeger met Access2 en het gebruik van Access97 vernachelde de access2.mdb.
Je kan zeggen dat iedere upgrade van Access uiteindelijk veranderingen aangebracht heeft
die door de oudere niet meer begrepen word(en). Voor de 2000 serie dus afgehaakt om deze reden.

Sorry als het te lang is.


(beter te lang dan geen )