Office: (Office 2010) Ideen für eine Auswertung

*Bing* Es geht ja nur um die Quote. Die ist - naturgemäß - ein Wert zwischen 0 und 1 = 0%-100%. Das wird scheinbar als Ganzzahl gedeutet und geht damit unter.

Lass mal Zähler und Nenner in explizite Dezimalwerte wandeln. Und probiers erstmal mit einem Feld, meinetwegen den offenen; wenn die klappen, ist der Rest dann analog.

Code:

Ein Malnehmen mit 100 wird nichts bringen, da 0 * 100 0 bleibt.

 

Das sieht schon mal besser !

Im Anhang ein Bild. Ich sollte nur Money in Prozent umstellen dann könnte was feines bei rauskommen.

NACHTRAG:

Ich habe die Abfrage an ein Formular gebunden und die Formatierung angepasst.

Sieht nun wie folgt aus.

 

Es gibt keinen Datentyp Prozent. Prozent ist allesnfalls ein Format, also eine Anzeigevariante. Wenn du den Dezimalwert 0,25 hast, entspricht das 25%, das Darstellen in % kann und soll aber das Ausgabemedium (Formular, Bericht) übernehmen.

Ziel erreicht?

 

Ergebnisse passen...

Jetzt kommt der lustige Teil das ganze in ein Formular zu packen.

Du hast ja gesehen das ich noch ein Bild mit dem Formular gepostet habe. Ich habe da den Datentyp auf % gestellt. Sieht gut aus.

Der nächste Schritt wäre nun die Abfrage dahingehend zu ändern das ich mit einem Parameter aus dem Formular die Daten selektiere.

Ich stelle mir das irgendwie so vor, das ich ein Hauptformular öffne auf dem ein Ufo Gebunden ist. Nach dem ich die Daten eingegebn habe Büro und Jahr. Kann ich per Knopf das Ufo öffnen und ich bekomme das ergebniss angezeigt was mit die Abfrage errechnet.

Würdest du es anders machen? Eventl in einem Pivot Chart ? Ich bin da ebenfalls für gute Ideen offen...

In der accdb konnte ich den Paramter so übernehmen
Code:

Das funktioniert so in der PT Abfrage überhaupt nicht.

 

Hi,

das gestaltet sich recht einfach: du brauchst lediglich die SQL der PT-Abfrage abzuändern - den jetzigen "Urzustand" der PT-Abfrage solltest du mal sicherheitshalber irgendwohin kopieren, von wo er notfalls wieder herkopiert werden kann, falls du dich vergaloppierst.

Code:

Die neue, komplette SQL muss in den fraglichen Stellen die Werte aus dem steuernden Formular übernehmen. Die SQL muss also "zusammenmontiert" werden. Da empfiehlt sich, die SQL "zeilenweise" in einer Variable aufzubauen und an den fraglichen Stellen die Formularwerte einzubauen, etwa nach dem Schema:
Code:

Die fraglichen Stellen sind IIRC Büro und Zeitraum. Denke also dran, diese bisher festen Werte durch solche Formularevrweise zu ersetzen.

Wenn die SQL-Variable dann montiert ist, dann kommt sie per QueryDefs-Mechanik (s.o.) in die Abfrage. Dann ist die Abfrage geändert. Das Formular, das auf diese Abfrage zugreift, kann dann geöffnet oder einem Requery unterzogen werden. Die neue Abfrage wirkt dann.

 

Also würde das Formluar aufgehen ohne eine Abfrage irgendeines Paramters? Ich gebe die Parmater in ein Textfeld ein und machen ein DoCmd.qry_Auswertung_Pt.Requery.... und schwubs ist alles da?

 

Ja. Alle parameter werden aus dem Formular ausgelesen und fix und fertig in die auszuführende Abfrage eingelötet.

Das darfst du aber selber machen *cool.gif*

So allerdings nicht. *Smilie Die Abfrage braucht kein Requery. Bau mal dein Formular, das die Parameter abfragt und in die Abfrage reinkloppt. Wenn das klappt, meld dich wieder.

 

Ich muss leider vorher Fragen!

Habe ich das so richtig verstanden?
Code:

Das habe ich in die PT Abfrage eingebaut! Muss das dort hin? Oder gehört das woanders hin

was mache ich mit dem Teil
Code:

??

 

Hi,

der Code gehört in einen Formular-Befehlsbutton. Eine Abfrage kann mit diesem VBA-Code nichts anfangen. Der VBA-Code "baut" die Abfrage ja neu auf.

Im WHERE hast du das Büro richtig ausgelesen, aber ab dem AND beginnt ein zweites Teilkriterium, das wieder mit festem Teil (Datums-Feldname) und Formularbezug (Datumswert) zusammengesetzt werden muss.

Der Formularbezug für das Belegdatum im WHERE ist außerdem, da Datum, als #yyyy-mm-dd# zu formatieren, damit es eine gültige Bedingung wird. Mich irritiert hier, dass das Formulartextfeld txtJahr heißt. Wenn da ein Datum dtrinsteht, ist txtJahr verwirrend; steht da wirklich nur ein Jahr drin, dann muss die Bedingung anders lauten, denn ein Jahr ist mit einem Datum nicht vergleichbar. Was also steht in txtJahr?

Außerdem fehlen Leerzeichen im zusammengefügten Text. Am besten lässt du immer jede Zeile mit einem Leerzeichen enden, dann passiert das nicht.

Und, letzlich muss die zusammenmontierte SQL natürlich auch in die Abfrage geschrieben werden. Das fehlt bisher ganz.

Also:
Code:

 

Entschuldige bitte aber ab hier

Dachte ich eben nur HÄÄ?? *grins Sei mir bitte nicht böse!

Also ich versuche es mal stück für stück nachzubearbeiten.

Erst mal die Info. im Feld txtJahr soll nur 2012 oder 2011 etc drin stehen sonst nichts!
Deswegen auch in der PTabfrage das Year!

Für was sind die Leerzeichen gut.... ??

Gestern dachte ich noch das ich diesen Code einigermassen verstanden hatte... Aber heiute packst du noch einen drauf :-) Naja das ist auch gut so.
Bei Code:

trage ich meine PT Abfrage ein?

 

Wenn du mehrere Zeilen zusammenfügst und dabei nicht am Ende jeder Zeile ein Leerzeichen hast, kleben die Zeilen zusammen und funktionieren nicht mehr. Beispiel FROM: das FROM klebt in deinem alten Code direkt hinter dem t von QuoteAbgesagt. Das wird dann nix.

DasmeinstdunichtimErnst!WennduallesohneLeerzeichenschreibstdannkannVBAdieBefehle nichtmehrerkennen.

Schön zu wissen *rolleyes.gif* Dann muss dieses Kriterium aber auch in das Kriterium mit rein. Da die meisten Jahre am 01.01. anfangen und am 31.12. enden, ist das recht einfach machbar. S.u.

Nein. Das ist alles Code für hinter den Button im Formular. In die Abfrage trägst du manuell gar nichts mehr ein, da sie vom Code jedesmal komplett neugeschrieben wird. Das habe ich jetzt aber auch schon mehrfach geschrieben. Versuch doch mal, zu lesen und zu verstehen.

Abgesehen davon hab ich noch übersehen, dass wir ja von T-SQL reden, da sind die Datumsformate anders ('yyyy-mm-dd').
Code:

 

Hallo,

das fehlende R ist mir direkt aufgefallen bei "CurrentDB"

hierbei: Code:

meinte ich eigentlich
Code:

auch das funktioniert.

Ich kann es nicht mehr wie lesen lesen lesen und versuchen nachzumachen so gut es geht.

Mir war es nicht bewusst, da ich nicht so der Profi in SQL bin (wie man merkt) das vor ein " noch ein Leerzeichen muss.

Wenn ich das Datum rauslasse bekomme ich eine astreine Abfrage erstellt.
Mit Datum mekert er was

kann ich das nicht mit diesem Year aus dem oberen Bereich machen?

Ich hatte ja auch vorher in der Abfrage
Code:

z.B.

 

Doch. Du kannst nachschlagen, was die Befehle (wie z.B. Currentdb.querydefs().SQL) tun, wenn es noch unklar ist.

Die kritischen Leerzeichen war die am Ende der Zeilen, die später ja zusammengefügt werden. Außerdem hättest du das auch sehen können, wenn du dir den zusammengesetzten strSQL mal in der Überwachung oder im Direktfenster ausgeben lässt.

Seltsam. Steht in dem Formulartextfeld tatsächlich nur ein Jahr (z.B. 2011)? Lass dir mal die entstehende Gesamt-SQL ausgeben und zeig sie her. Es sollte schon so funktionieren.

Der Ansatz mit Year(Bestelldatum) = Formulareingabe geht zwar auch, verhindert aber die Indexnutzung auf dem Server und ist damit tendenziell langsamer. Probiers halt mal aus; ersetze den Datumsvergleich durch einen Vergleich mit dem Jahr.

 

Das hier baut er zusammen,
Code:

 

UUpppss,
ES GEHT !!

hier der Code!!
Code:

Im ANhang ein Bild wie das Formular aussieht... Ich denke da werde ich noch bischen was dran machen...