1.5 veranderen naar geldbedrag

[Visara]

Goedeavond,

Hoe kan ik
1.5
0.75
38
veranderen in data die weergegeven kan worden als geldbedragen?
Kan ik het beste met een VBA-code alle eventueel aanwezige PUNTEN in vervangen door KOMMA'S? (alleen in 3 specifieke kolommen van tabellen)
Hoe zou die code er uit zien?
Is dit überhaupt een handige manier van werken?

Context:
Ik ga wekelijks een XML-bestand ontvangen. Hier staan artikelgegevens in. Dit XML-bestand vervangt het vorige bestand.
Ik laad dit XML-bestand handmatig in de database ('New Data Source' - 'From file' - 'XML File'). Omdat het de vorige tabel moet vervangen wis ik die oude tabel eerst nog even.
Het resultaat is een tabel met de naam 'product' en een tabel met ImportErrors. Deze ImportErrors gaan over niet interessante gegevens, dus daar besteedt ik geen aandacht aan.
Deze tabel 'product' bestaat uit zo'n 80.000 records.

Mbv 'Append Query's' splits ik de tabel in tabellen per leverancier. Deze tabellen bevatten alleen de voor mij interessante kolommen.
Deze tabellen dienen in een andere database als 'Linked Tables'. Er wordt door de gebruiker niet in deze tabellen gewerkt, alleen info uit gehaald met 'Append Query's' en 'DLookUp functies' in formulieren.
In 3 kolommen kúnnen geldbedragen staan (kan ook een leeg veld zijn). Kolomnamen 'statiegeld', 'inkoopprijs' en 'consumentenprijs' bevatten geldbedragen. Deze bedragen zijn echter opgeslagen als bijv 1.5 (met een punt dus).

Ik heb als bijlage de database toegevoegd met slechts een handvol records ipv de 80.000. De inkoopbedragen zijn door mij aangepast omdat dit gevoelige gegevens zijn.

Met vriendelijke groet,
Visara

 

[NoellaG]

Hallo, je kan in je append query de functie Replace gebruiken, vb:

SELECT Replace([tblTest]![tstNumber],".",",") AS fldNr FROM tblTest;

 

[Visara]

Die code werkt, dankjewel

Tot mijn verbazing kan ik aan het einde van de complete SELECT regel het stukje 'AS fldNr' zetten, zonder dat dit verkeerde invloed heeft op de andere kolommen.
Eerst zette ik de 'AS fldNr' achter elk stukje met 'Replace', maar daar was Access het niet mee eens.

INSERT INTO tabel1039 ( kolom1, kolom2, kolom3, kolom4 )
SELECT kolom1, Replace([product]![kolom2],".",",")[B][COLOR="#FF0000"] AS fldNr[/COLOR][/B], kolom3, Replace([product]![kolom4],".",",") AS fldNr
FROM product
WHERE product.leverancier="1039";

Dat rode moest en kon tot mijn verbazing weg

Bedankt voor uw hulp.

 

[NoellaG]

"as fldNr" dient alleen als alias om het berekende veld een naam te geven en heeft niets te maken met de berekening zelf. Als je dat niet doet dan worden in de resultset de veldnamen field1, field2 enzovoort gebruikt.
In je instructie geef je 2 keer hetzelfde alias als naam en 2 velden met dezelfde naam geven moeilijkheden. Zeker als je de instructie in een insert geeft hoef je de velden niet te benoemen en is het zelfs beter om het niet te doen.

INSERT INTO tabel1039 ( kolom1, kolom2, kolom3, kolom4 )
SELECT kolom1, Replace([product]![kolom2],".",",") , kolom3, Replace([product]![kolom4],".",",") 
FROM product
WHERE product.leverancier="1039";

 

[OctaFish]

Als je dat niet doet dan worden in de resultset de veldnamen field1, field2 enzovoort gebruikt.

Volgens mij krijg je Expr1, Expr2 als standaardnamen in een berekening als je niks zelf bedenkt. Overigens is het altijd aan te bevelen om wél logische namen in formules te gebruiken, zodat je later weet wat de waarde voorstelt.

 

[OctaFish]

@Visara: als ik jou was zou ik eens goed naar de tabellen (vooral Product) kijken, want daar zou ík niet mee willen werken . Lijkt mij dat daar het e.e.a. aan te verbeteren valt

 

[Visara]

@NoellaG
Bedankt voor je uitleg.
Zoals je vermoedelijk in de gaten had, dacht ik dat de 'AS fldNr' een onderdeel was van de 'Replace'-functie. Vandaar mijn verwarring.

Zo ziet mijn code er nu uit:

Private Sub cmdPopulate_Click()
DoCmd.SetWarnings False
DoCmd.RunSQL "DELETE * FROM 1001_1116_Udea;"
DoCmd.RunSQL "DELETE * FROM 1039_Odin;"
DoCmd.OpenQuery "q1001_1116_Udea"
DoCmd.OpenQuery "[COLOR="#FF0000"]q1039_Odin[/COLOR]"
DoCmd.SetWarnings True
End Sub

Query q1039_Odin:

INSERT INTO 1039_Odin ( eancode, omschrijving, inhoud, eenheid, statiegeld, merk, kwaliteit, btw, cblcode, bestelnummer, sve, bewaartemperatuur, inkoopprijs, consumentenprijs, ingangsdatum )
SELECT eancode, omschrijving, inhoud, eenheid, Replace([product]![statiegeld],".",","), merk, kwaliteit, btw, cblcode, bestelnummer, sve, bewaartemperatuur, Replace([product]![inkoopprijs],".",","), Replace([product]![consumentenprijs],".",","), ingangsdatum
FROM product
WHERE product.leveranciernummer="1039";

De tabellen zoals tabel '1039_Odin' dienen als externe tabel voor de database waar de gebruiker écht in werkt. Worden er een stuk of 10, voor elke leverancier een tabel.
Deze externe tabellen, zoals '1039_Odin', worden alleen 'bekeken' door de gebruiker, er wordt niks in aangepast of toegevoegd.
Gegevens uit deze externe tabellen worden weergegeven in tekstboxen in een form. In deze tekstboxen staat bij bijv 'Omschrijving' de volgende formule:

=IIf(DLookUp("[omschrijving]";"1039_Odin";"[bestelnummer]=" & "[Forms]![fOverzicht].[besteld]");DLookUp("[omschrijving]";"1039_Odin";"[bestelnummer]=" & "[Forms]![fOverzicht].[besteld]");DLookUp("[omschrijving]";"1039_Odin";"[eancode]=" & "[Forms]![fOverzicht].[besteld]"))

'kokosstart framboos(6)' is een voorbeeld van een omschrijving.


@Octafish
Bedankt voor uw reactie
De tabel 'product': die komt van externe partijen in XML-vorm zo binnen.
Als ik het nieuwste XML-bestand binnen krijg laad ik die in de database en dan ziet het er uit als tabel 'product'.
Ik doe dan slechts 1x iets met die tabel, namelijk hem splitsen dmv de besproken AppendQuery's. Ik zou daarna die tabel 'product' eventueel gelijk kunnen verwijderen om opslagruimte te sparen.
Wel nog even 'Compact and Repair', anders bespaar ik alsnog niks qua ruimte.
Dat ik ruimte wil besparen door een tabel te wissen waar ik verder niets mee doe is omdat ik denk dat 'DLookUp'-functies dan sneller werken, maar dat weet ik eigenlijk helemaal niet zeker. Misschien laadt Access alleen de tabellen waar naar wordt gekeken, misschien de complete database. Geen idee.
De gebruiker gebruikt alleen gegevens van deze database, de tabellen in deze database worden door de gebruiker niet bewerkt.

 

[OctaFish]

Worden er een stuk of 10, voor elke leverancier een tabel.

Heb je enig idee hoe slecht zo’n oplossing is? Ook de formules die je gebruikt om de tekstboxen te vullen getuigen niet van een slimme aanpak. Het kan, als ik het zo (weliswaar van grote afstand) bekijk, echt een heel stuk slimmer en vermoedelijk ook beter onderhoudbaar gemaakt worden.

 

[Visara]

Een relatie tussen tabellen is voor mijn toepassing alleen zinvol als dit snelheid oplevert, denk ik? De database dient als een hulpmiddel voor de gebruiker om zijn bestelling zichtbaar te maken, aan te passen en daarna te verzenden.
Er hoeft NIETS van zijn handelingen bewaart te worden.
Ik ben dus niet zozeer een klassieke database aan het bouwen, meer een bestelapplicatie.

De input van de gebruiker is een .txt bestand met daarin een kolom getallen (bestelnummers en/of EAN-codes)
De database is er voor zodat de gebruiker kan nalopen wat hij besteld heeft, zie screenshot:

In dit fictieve voorbeeld heeft de gebruiker ook per ongeluk iets besteld dat deze leverancier niet kent, zie de regels waarin de zoekfunctie geen omschrijvingen heeft gevonden.
De gebruiker ziet zijn bestelling op volgorde van hoe hij het besteld heeft, dus hij kan daardoor relatief makkelijk uitvogelen welke producten onbekend zijn (misschien hangt er een verkeerd schapkaartje bij een product?)
De gebruiker kan de bestelling aanpassen indien gewenst.
Daarna kan de output gemaakt worden, een mail naar de leverancier met .txt-bijlage van de bestelnummers en aantallen.

De tabel waar de bestelling in terechtkomt wordt bij elke sessie leeggemaakt met DoCmd.RunSQL "DELETE * FROM tabelnaam"
Die gewiste records blijven, totdat je 'Compact and Repair' doet, wel ruimte innemen. Dat zou anders kunnen, maar ik weet niet hoe.

Als ik een relatie maak tussen de nummers in de bestelling en tussen de bestelnummers van de leverancier, dan zal ik er eerst iets op moeten vinden dat de EAN-codes worden omgezet naar bestelnummers.
Maar dan ben ik er nog niet, want een gebruiker kan een niet bestaand bestelnummer invoeren. Dit moet wel zichtbaar blijven zoals in het screenshot, en hoeft pas verwijderd te worden als de emailbijlage voor de leverancier wordt gemaakt.
Er hoeft niets van de handelingen bewaart te worden.

Ik ben zelf al een jaar of 15 gebruiker van bestelapplicaties, en vanwege onvrede over die programma's probeer ik zelf iets te maken voor ons eigen gebruik.
Vanuit de gebruiker gezien weet ik precies wat ik wil in de applicatie, van het 'onzichtbare' stuk op de achtergrond heb ik veel minder verstand.

 

[NoellaG]

Dag Visara,
als je een goede relationele structuur hebt opgebouwd, samen met de juiste indexen, dan kan je met SQL instructies veel sneller zoeken dan welke lookup ooit kan doen. Een lookup moet immers altijd de hele tabel bekijken (full table scan), terwijl SQL de zoekinstructie in stukken breekt (parsen van de instructie), en daarna het snelste zoekpatroon ( query plan) gaat opbouwen en dit dan gaat uitvoeren. Dit proces is, in een goed opgebouwde database, veel sneller dan de full tablescan van een lookup.
Maar je merkt, de snelheid is afhankelijk van een goede opbouw én het correcte gebruik van indexen. Dus ik zou mijn database niet veranderen voor je wat tijd hebt gestoken om deze dingen te bekijken. Er is geen probleem om verder te werken met het systeem zoals je nu doet , dat is immers de manier waarop de mega grote databases zoals google en Hadoop werken. Let wel op dat de Access machine gebouwd is om met relaties te werken en zolang je Access gebruikt is het dus ook aan te raden om volgens die methodiek je database op te bouwen.

Succes
Noëlla

 

[Visara]

Bedankt voor je uitleg. Wordt gewaardeerd!