MS Access - Datenformat bei Abfrage festlegen bzw. Runden

Piktogramm

Fleet Admiral
Registriert
Okt. 2008
Beiträge
10.028
Servus,

ich habe zwei Spalten in Access (Datentyp: Single, 2 relevante Nachkommastellen, Wertebereich 0..1). Bei Einder Abfrage ist Spalte 1 von Spalte 2 zu subtrahieren.
Bis dahin habe ich es geschafft ;)

Nur wie überrede ich jetzt Access anstatt völlig dämlicher Exponentendarstellung, das Ergebnis aus 2 Nachkommastellen genau anzugeben?

Istzustand (funktioniert:
Code:
SELECT ..., [Spalte1]-[Spalte2] AS Differenz

Da es ja eine Rundenfuktion gibt dacht ich mir, tjo gleich nutzen!


Code:
SELECT ..., Round(([Spalte1]-[Spalte2]);2) AS Differenz

Tja denkste, geht ÜBERHAUPT nicht. Gibt Syntaxfehler zurück. Das Smikolon habe ich noch auf Verdacht gegen ein Komma getauscht, dann läuft die Abfrage zwar aber es wird nichts gerundet.

Für Vorschläge bin ich offen.


PS: Der TE ist gerade am Kotzen, da er feststellen muss, dass das deutsche Access teils auch die Syntax eingedeutscht hat. Also Die SQL Syntax ist in englischer Sprache, die Syntax in der Entwurfsansicht aber Deutsch. Muss ich los werden!
 
Hmm, eigentlich ist es nicht Aufgabe des Statements, die Darstellung zu übernehmen. Runden sollte es ja schon richtig. (Funktioniert bei mir mit Access 2003 so wie es soll).
Ich weiß nicht, wo du die Daten ausgibst, aber möglicherweise kann man da was drehen (in dem Formular kann man ja angeben, auf wie viele Nachkommastellen gerundet werden soll).
 
In Formularen etc. geht das. Nur in simplen Abfragen=!

Der aller größte Witz ist auch, ich habe die Lösung vom Kommilitonen. In einem Access Projekt funktioniert der ganze Spaß, bei identischer Ausgangslage.

Unterschiede die bestehen: Er hat es auf einer älteren Access Version erstellt. Was ja aber nicht den Unterschied machen dürfte, da ja mein Access die eigentlich Abfrage berechnet.
Ergänzung ()

@Shagrath: JUHUUUUU, was die richtigen Suchbegriffe alles ermöglichen :) DANKE DANKE

Jetzt habe ich zwar noch immer das Rätsel wieso "Round" nicht funktioniert und wieso das Verhalten im Projekt des Kommilitonen ein Anderes ist aber hey, es tut erstmal*!



*Ich hasse Dinge die "tun" aber für mich nicht ersichtlich wieso sie "tun" was sie "tun" :/
 
Das ist mir klar, viel mehr interessiert mich wieso bei zwei Projekten die augenscheinlich gleich sind eine derartige Differenz vorherrscht ;)

Daher ich hab eine EDV Lösung bei der ich nicht sicher sein kann, das Ergebnis genau reproduzieren zu können und wo ich sagen muss, ich hab es nicht verstanden wieso das Verhalten unterschiedlich ist. Sowas macht mich fertig ;)
 
Zur unterschiedlichen Darstellung: http://social.msdn.microsoft.com/Fo...isplay-in-scientific-notation?forum=accessdev
http://www.brighthub.com/computing/windows-platform/articles/79460.aspx
Ich denke, es hängt mit der Zellenbreite zusammen. Bei den Formularelementen kann man es unter Access2007 scheinbar erzwingen.

Unterschiedliches Verhalten kommt öfters vor (such mal nach "DLL-Hell" z.B.), daher sollte man möglichst standardkonformen Code schreiben, damit der nicht arg falsch von einem späteren Programm verstanden werden kann.
 
:heulDie Zellenbreite ist unbdeutend, bei zu schmalen Zellen gibt es bei mir das allseits belibte "######" ;)

Möglichst Standard konform :heul:: ich habe ja schon geschrieben, an einigen Stellen wurde die Syntax eingedeutscht und die englischen Funktionsnamen funktionieren an den Stellen nicht. Standardkonform kann man so überhaupt nicht schreiben* (die selbe Hölle wie bei Excel!).
Anyway ich bin fertig, habe ein paar Sachen deren Verhalten ich NICHT erklären kann und da bin ich mal gespannt was dazu dann in der Auswertung gesagt wird :D


*Oder man richtet sich Access & Word in stundenlanger Arbeit so ein, dass es doch geht um dann in deutlich kürzerer Zeit die eigentliche Arbeit lustlos zusammen zu klicken :/
 
Zurück
Oben