Office: (Office 2010) Textfeld nach Kriterium im Datumfeld ausfuellen

Hallo!

Irgendwie ist zumindest mir langsam der Überblick verloren gegegangen. Wo kommt denn in Deinem SQL-Srting der Ausdruck "(SiInm(([Dias deudas]

 

... gut zu verstehen das man da den Ueberblick verliert.. Sorry "Ich komm also noch mal neu rein" *wink.gif* und versuchs zu erklaeren.

Ich habe ein Kundentabelle , in dieser Tabelle stehen die Stammdaten und auch wann der kunde das letzte mal bezahlt hat, sowie bis wann er das letzte bezahlt halt. Also sowas wie Fecha_ultima_cancelacion (was heisst datum der letzten Zahlung), und Pago_Hasta ( was heisst bezahlt_bis) also z. B. bis 30/05/2012. Diese Daten werden pe hand eingetragen.
Dank dem Hinweiss von Anne dann anschliessend das Formular ueber eine Abfrage zu machen habe ich in diese Abfrage dann auch gleich weitere Felder erzeugt, ueber die ich dann dem User einen nuetzlichen Ueberblick ueber den Zahlungszustand / Estad_Financiero gebe.
Diese felder sind berechnet Z B.
Estado_Financiero: SiInm(([Dias deudas]>> Estado_Financiero: SiInm(([Dias deudas]

 

Hallo,

zeige bitte den SQL-Code dieser Abfrage, also von dem nicht funktionieren Versuch, damit wir sehen, wo der Fehler liegt.

Abfragen kann man genauso wenig "beschreiben" wie Programme, man muss den Code sehen, um ihn analysieren zu können.

 

Hola Anne,
hier de Code:
SELECT Clientes.CodigoCL, Clientes.Nombre, Clientes.Dirección, Zonas.Zona, Clientes.Pago_hasta, Clientes.Ultima_Revision, IIf(([Dias_deudas]

 

Hallo!

Danke für den vollständigen SQL-String Deiner Abfrage. Diese Abfrage sieht für mich gut aus und sollte funktioneren.

Was ist Dein Problem mit dieser Abfrage?
Welcher Parameter, den Du nicht erwartest, wird erfragt?

CU

 

Hallo Pelon.
Der Fehler liegt wohl daran, dass der Alias dias_deudas in der einen Abfrage berechnet und gleichzeitig im Kriterium sowie als Operand bei zwei weiteren Berechnungen verwendet wird.

Das wird nicht klappen: entweder Du kaskadierst das, indem Du eine Abfrage erstellst, in der dieser Wert berechnet wird und auf das Ergebnis dieser Abfrage erstellst Du eine neue Abfrage, die sich dann auf dieses Alias beziehen kann.

Oder Du verwendest statt des Alias an den beiden Stellen wiederum die ursprüngliche Berechnungsformel.
Setze also überall, wo Du dich auf dies_deudas beziehst, dies ein: Code:

Im Übrigen liest der Code sich deutlich besser, wenn Du Code-Tags verwendest ...

 

Nebenbei:
Code:

Wie kommt man auf so ein Kriterium?
Code:

... erfüllt das Gleiche und ließe sogar eine Indexnutzung zu.

 

Hallo!

Wenn wir schon beim Optimieren sind, dann wäre obiges Kriterium auch zu hinterfragen. Entwerder der Inhalt des Feldes ist "Conectado" oder er ist nicht "Suspendido" oder nicht "cortado". Da "Conectado" nicht "Suspendido" und auch nicht "cortado" ist, ist dieser Teil der Bedingung überflüssig. Das Kriterium wäre also:
Code:

Unter Verwendung der IN-Klausel geht es noch etwas kürzer. IMHO wird die Bedigung dadurch auch leichter lesbar und somit verständlicher:
Code:

CU

 

Hallo, Code:

das funktioniert so nicht, auf berechnete Felder kann man in der Where-Klausel nicht Bezug nehmen.
So sollte es gehen: Code:

 

... was man nicht alles erkennt, wenn man überflüssige Klammern und Ausdrücke entfernt.

Die Aussage, dass der WHERE-Teil vor dem SELECT-Teil ausgeführt wird und somit berechnete Felder noch nicht bekannt sind, trifft allerdings gleichfalls auf den Zustand vor meinem Hinweis zu.

 

Etwas weniger verklausuliert, könnte man deinen Kommentar evtl. verstehen, aber so... *confused.gif*
Möchtest du evtl. lediglich den "Schwarzen Peter" weiterreichen, der dir "ungerechterweise" zugeschoben wurde?!


Der Vollständigkeit halber wollte ich gern noch folgenden Kommentar loswerden:
So etwas funktioniert auch nicht erwartungsgemäß: Code:

da (wenn schon) das zweite OR ein AND sein müsste.
Besser ist wahrscheinlich der Vorschlag von Thomas mit der IN-Klausel, aber ganz genau weiß man ja nicht, was du da überhaupt abfragen willst.

 

Was bitte ist "verklausuliert" und unverständlich?