Bei der Verwendung eines cfinput vom Typ “datefield” kann es zu Problemen beim Parsen bzw. Konvertieren des zurückgelieferten ODBC-Datumsobjekts mit den ColdFusion-eigenen Funktionen (LSParseDateTime, LSDateFormat) kommen. Das liegt daran, das die UI-Komponente ein reines Datumsobjekt (z.B. {d ’2011-05-09′}) und nicht ein vollständiges DatumZeit-Objekt (z.B. {ts ’2011-05-09 13:13:15′}) als Ergebnis zurückliefert.

<cfform action="#CGI.SCRIPT_NAME#" method="post">
  <cfinput
    type="datefield"
    name="termin"
    id="termin"
    class="pflichteingabe"
    firstdayofweek="1"
    validate="eurodate"
    validateat="onSubmit,onServer"
    mask="dd.mm.yyyy"
    value="">

  <cfinput
    type="submit"
    name="btnSubmit"
    value="senden">
</cfform>

<cfdump var="#form#">

Weiterlesen »

Bei einem unserer Kunden gab es in den letzten Monaten vermehrt Datenbankfehler, sogenannte Deadlocksituationen, die offensichtlich mit einem Anstieg der Nutzerzahlen zusammenhingen:

“[Macromedia][SQLServer JDBC Driver][SQLServer]Die Transaktion (Prozess-ID X) befand sich auf Sperre Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.”

Weiterlesen »

Im aktuellen Projekt gibt es die Anforderung, dass Datensätze nicht physikalisch aus der Datenbank gelöscht werden dürfen, sondern lediglich als “gelöscht” markiert werden sollen.

Um das umzusetzen gibt es verschiedene Ansätze, in der Regel gibt es in den entsprechenden Tabellen eine “deleted” Spalte. Solange der Wert null ist, ist der Datensatz “da”, ist er != null, dann ist er “gelöscht”.

Weiterlesen »

Laut Livedocs für Coldfusion 8 sollte cfquery mit cfqueryparam und cachedWithin ja nicht funktionieren: “You cannot use the cfquery cachedAfter or cachedWithin attributes with cfqueryparam.” Stimmt gar nicht…!

Der (die, das,…?) Query

<cfquery
     name="qWerk"
     datasource="#application.dsn#"
     cachedwithin="#CreateTimeSpan( 0, 1, 0, 0 )#">
          SELECT werk_id, werk, organisation, sichtbar
          ...

in CF8 führt nach dem zweiten Aufruf zu:

Ich vermute mal, mit dem 8.01 Update kam die Möglicheit Queries mit cfqueryparam auch zu cachen. Steht aber leider nicht in der Doku. Erst bei den CF9 Livedocs fehlt der Hinweis. Gut also, das wir die Doku immer erst hinerher lesen…

Bin gerade bei einem Kunden über einen Query mit Like-Operator gestolpert, der mit einem cfqueryparam versehen werden soll:

SELECT ...
WHERE UPPER(CONVERT(varchar(500), a.keywords)) like '%#UCASE(x)#%'

Stellte sich zunächst die Frage, wohin mit den Paltzhaltern (%), in die value-Eigenschaft von cfqueryparam oder außerhalb vom Tag? Nach einem kurzen Test war klar, funktioniert unter CF8 nur, wenn der oder die Platzhalter innerhalb der value-Eigenschaft von cfqueryparam angegeben werden:

SELECT ...
WHERE UPPER(CONVERT(varchar(500), a.keywords)) like
<cfqueryparam cfsqltype="cf_sql_varchar" value="%#UCASE(x)#%">

Ich sitze zur Zeit bei einem Kunden, der eine über die Jahre etwas wild gewachsenen Coldfusion-Anwendung laufen hat und suchte nach der Ursache für den in der Überschrift genannten Fehler, der nach einer nur minimalen Änderung an x-fach verschachtelten cfif-Bedingungen auftrat. Das Ergbnis aus den Bedingungen wird in einem cfquery verwendet und an dieser Stelle tritt auch der Fehler auf. Dank des Debuggers im Coldfusion Builder stellte sich dann allerdings bald raus, das am Ende der Bedingungsprüfungen gar kein Inhalt raus kam, das cfqurey-Tag also gar nichts an die Datenbank sandte!

Zusammenfassend (und für meine interne Wissendatenbank aka Gehirn): Verwende niemals, niemals nicht ein leeres cfquery! Bzw. überprüfe sehr genau die Logik, die zum Füllen des cfquery-Tags verwendet wird.

Unser Kollege Dirk teilte gerade folgendes mit: falls Ihr mal das Problem haben solltet, dass Unicode (utf-8 oder utf-16) unter Verwendung von ColdFusion nicht korrekt in einer MS SQL Server DB gespeichert hier ein paar Tipps.

Auffallen tut das Problem dadurch, dass in den Spalten nicht der Text steht, der da eigentlich rein soll. Das betrifft natürlich “nur” Zeichen, die außerhalb der von uns normalerweise verwendeten Zeichentabelle liegen, also besondere Umlaute, aber z.B. auch die griechischen oder kyrillischen Buchstaben.

Weiterlesen »