Decimalen niet kwijt te raken

  • Onderwerp starter Onderwerp starter Johgs
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
J

Johgs

Gebruiker
Lid geworden
19 mei 2011
Berichten
340
In een tabel zit een veld met enkel gehele getallen, zo ingevoerd maar ook op Integer gezet en geen decimalen.
In de tabel zie je geen decimalen.
Voor een invulveld heb ik een query gebaseerd op die tabel die o.a. het veld met dat getal op haalt, kijk ik in de query zie ik gehele getallen.
Echter in het formulier in het invulveld zie ik de getallen terug met ,00.
Er wordt bij een keuze keurig een geheel getal ingevoerd zonder ,00

Het ziet er echter zeer slordig uit dat in dat uitklapkeuze menu'tje wel die ,00 er achter staat. Met allerlei instellingen geëxperimenteerd maar raak die ,00 maar niet kwijt.
 
Geen idee wat er aan de hand is; doe er een voorbeeldje bij, zou ik zeggen.
 
Om gek van te worden, ik maak vanaf 0 een dB met tabelletje, query en form met keuzeinvulveld met dezelfde instellingen en het gaat wel goed.

Blanco form in de dB met een enkel invulveld gebaseerd op een nieuwe query en weer die twee nullen achter de komma. Terwijl een gewoon veld met als bron dezelfde query wel decimaalloos blijft in hetzelfde formulier.

Helaas is de dB zo'n 15 Mb groot en dat zonder data. Zou graag een voorbeeldje sturen want ergens moet er een instelling verborgen zijn die de oorzaak is.
 
15mb voor een lege db? Onmogelijk! Tenzij je allerlei plaatjes op je formulieren hebt gezet, en dan niet als koppeling maar embedded. Maar we hoeven alleen maar de betreffende tabel (met een paar records), de query en het formulier te hebben waar het om gaat. De rest hoeft er niet in te zitten. Heb je de db wel gecomprimeerd? Want dat kan ook nog een oorzaak van de grootte zijn.
 
Gecomprimeerd en wel. En nee, niets embedded, alle data staat in de backend op één enkel tabelletje met enkel de locatienaam.
Zal eens kijken of ik het benodigde deel kan afzonderen, want het betreft data uit meerdere tabellen, een formulier dat samengesteld wordt op basis van ingevulde data in voorliggende formulieren en een query die selectiecriteria gebruikt uit meerdere formulieren.

Of is de omvang zo groot weergegeven omdat de data uit gekoppelde tabellen wordt meegeteld?
Ik werk over het algemeen met een thin cliënt, en merk bij kopiëren of verplaatsen dus niets van de werkelijke omvang van een bestand, groot of klein, het lijkt even snel te gaan.
 
Kopiëren van een bestand van 15mb zal je nauwelijks merken, want dat telt niet echt mee in de huidige tijd.. De grootte van een db met gekoppelde tabellen zou juist in de Frontend heel klein moeten blijven, omdat je geen data in de FE zelf hebt. De BE zal dan wel groeien bij mutaties maar de FE dus niet. Ben toch benieuwd wat die grootte rechtvaardigt :). Is hij ook zo groot als je 'm zipt?
 
Pittig :). Probeer 'm toch maar wat kleiner te maken, zou ik zeggen. We hebben niet zoveel nodig om het probleem te kunnen zien.
 
Staat in bericht #1 :D
 
@Johgs: kun je de db niet op een Fileshare zetten? Kunnen we alvast aan de slag...
 
had ik gelezen octafish maar dat was de instelling in de tabel. Moet je in een formulier niet weer instellen wat de getal notatie is zodat je het aantal decimalen kunt instellen. ik heb hier ook weleens problemen mee.
 
Een formulier neemt doorgaans de instellingen van de tabel netjes over. Ook dat heeft TS trouwens al gemeld. Het gaat pas fout in de query. Dus we zullen de query erbij moeten hebben voor een beter idee.
 
Al even wat bezig geweest met wissen, maar toch net weer teveel gewist. Probleem is dat dB opent met een vast formulier (met gelijk al 18+1 keuze opties) dat voor de lokatie al veel verborgen waarden instelt die in vanuit dit formulier geopende formulieren, die zelf weer wat keuzeopties toevoegen, weer een volgend formulier opent enz enz. Ga je slopen, moet je weer instellingen toevoegen, in een haastklusje ging dat fout en daarna een vergadermiddagje.....

O, in de query staat het nog goed, pas als de waarde in het formulier gekozen wordt, komen die 2 nullen achter de komma........ hee..... eens kijken of er op de één of andere manier een valuta instelling zit....
 
Laatst bewerkt:
Zo, even flink aan het wissen geweest en tot de ontdekking gekomen dat als je gekoppelde tabellen wist en vervangt door lege kopieën je query's niet meer werken, dus ook het nodige weer bij moeten werken. "Gelukkig" is de fout wel gebleven.
Het bijgaande bestand opent bij aanklikken in "gebruikersmodus" met het openingsscherm, ik heb alle niet relevante opties uitgegrijsd en via de enig overgebleven opties (kies bij onderdeel dummy1) kom je op het betreffende formulier met in de linkerkolom het probleem met de ,00. Ik heb een deel van het formulier dat niet relevant is ook moeten wisssen en de bijwerkquery die kolom 2 bijwerkt na kiezen in kolom 1 en omgekeerd is ook uitgeschakeld. Het wissen van de gekoppelde tabellen en vervangen door lege (met enkel de structuur) zorgde voor tabellen zonder velden en dus verdwenen joints, even geprobeerd te herstellen, maar niet relevant voor het probleem dus maar weggelaten.

Nieuw probleem, gezipt bestand van 431 kb is te groot....

Oplossing: https://www.dropbox.com/s/l3qid6w093nsy4o/HelpMij.zip?dl=0
 
Je probleem ligt, zoals eigenlijk al te verwachten, in je tabel. En nu zie je ook gelijk waarom het zo belangrijk is dat je met een voorbeeld db komt, want je weet zelf blijkbaar niet goed hoe e.e.a. werkt. En door ons de (achteraf) verkeerde informatie te geven, die in jouw ogen wél goed is, kunnen wij natuurlijk nooit raden dat er wel degelijk een fout in je db zit. Nou ja, fout: een gedachtenfout bij jou.

Johgs zei:
In een tabel zit een veld met enkel gehele getallen, zo ingevoerd maar ook op Integer gezet en geen decimalen. In de tabel zie je geen decimalen.
Klik om te vergroten...
Je dénkt namelijk dat je geen decimalen hebt ingesteld, maar dat heb je wel degelijk wél gedaan! Je hebt bij de veldnotatie namelijk ingevuld: Vast. En vast is voor Access: een opmaak met 0,00. Oftwel: een getal met 2 cijfers achter de komma! Vervolgens heb je het aantal decimalen op 0 gezet, en daarmee denk je dan: nu heb ik een Integer getal met 0 cijfers achter de komma. Nee dus: je hebt een integer getal met 2 cijfers achter de komma waarvan je er 0 wilt zien! En dat is heel wat anders :).
En dat gaat allemaal prima zolang je queries gaat maken waar dat veld als zelfstandig object in staat, maar je keuzelijst is in dit geval een samengesteld object uit meerdere elementen, waaronder een tekstveld. In dat geval krijg je in de keuzelijst de oorspronkelijke instelling te zien van je veld: een Integer met de notatie Vast. Oftewel: 1,00 en 11,00. Simpel op te lossen natuurlijk door de notatie gewoon leeg te laten.
 
Nou, oorspronkelijk niet op vast gezet, dat is later gebeurd bij pogingen die ,00 weg te krijgen.
Gestart met standaard instellingen, die vast is pas bij het experimenteren verschenen.
Kennelijk toch meerdere instellingen tegelijk geprobeerd of vergeten een vorige weg te krijgen.

In ieder geval blij dat het nu opgelost is.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan