Eigene SQL-Anweisungen

Mit XDEV 5 können Sie Datenbankabfragen auch direkt in SQL formulieren. Da der Java-Compiler keine SQL-Anweisungen verarbeiten kann, stellt XDEV 5 die Methoden query( ) und write( ) in verschiedenen Ausführungen (überladen) für das Absetzen von SQL-Anweisungen zur Verfügung, die Sie in der Bibliothek DBUtils finden.

Die mit query( ) und write( ) formulierten Abfragen werden immer an die aktuell gesetzte Datenquelle versendet. Mit Hilfe der Methode setDataSource( ) können Sie jederzeit während der Laufzeit eine andere Datenquelle setzen. Neue Datenquellen können über das Menü Neu anlegen.

Mit der Methode query( ) können Sie eine beliebige SQL-Anweisung als String übergeben. Das Abfrageergebnis wird in einer Virtuellen Tabelle gespeichert, die zur Entwicklungszeit in XDEV 5 angelegt werden muss. Die Methode query( ) muss in einem Try-Catch Block ausgeführt werden.

try

{

DBUtils.query(Fahrzeuge.VT,"SELECT * FROM Fahrzeuge",null);

}

catch(DBException e)

{

// TODO Auto-generated code

e.printStackTrace();

}

Mit dem optionalen Parameter Object[ ] params können Sie bei Bedarf zusätzliche Parameter angeben, die via ? Platzhalter in den SQL-String eingefügt werden. Die Parameter müssen in derselben Reihenfolge wie die jeweils dazugehörigen ? Platzhalter angegeben werden. Wenn Sie keine weiteren Parameter angeben, können Sie für Object[ ] params wahlweise null angeben oder diesen Parameter vollständig weglassen.

XdevDate start = dateTextfieldStart.getDate();
XdevDate end = dateTextfieldEnd.getDate();
try
{
    DBUtils.query(Fahrzeuge.VT,"SELECT * FROM Fahrzeuge WHERE Erstzulassung >= ? AND Erstzulassung <= ?",start,end);
}
catch(DBException e)
{
   // TODO Auto-generated code
   e.printStackTrace();
}

Sie können jedoch auch speziell für dieses Abfrageergebnis eine Virtuellen Tabelle als Instanz erzeugen. Die Angabe einer statischen Virtuellen Tabelle wie Fahrzeuge.VT ist dann überflüssig und der Parameter damit null. Der Zugriff auf die erzeugte Virtuelle Tabellen Instanz erfolgt über eine Variable vom Typ VirtualTable.

try

{

VirtualTable fahrzeugeVT = DBUtils.query(null,"SELECT * FROM Fahrzeuge",null);

}

catch(DBException e)

{

// TODO Auto-generated code

e.printStackTrace();

}

●query(VirtualTable vt, SELECT select, Object[] params) : xdev.vt.VirtualTable

Dies ist die Standard-Methode für schreibende Datenbank-Zugriffe, mit der Sie eine SQL-Anweisung als String übergeben können. Mit dem optionalen Parameter Object[] params können Sie bei Bedarf eine Liste zusätzlicher Parameter angeben, die via ? Platzhalter in den vorangehenden SQL-String eingefügt werden. Als Rückgabewert wird die Anzahl der geänderten Datensätze zurückgegeben.

int id = ...;
float kilometerstand = ...;

try

{

DBUtils.write("UPDATE Fahrzeuge SET Kilometerstand = ? WHERE ID = ?",kilometerstand,id);

}

catch(DBException e)

{

// TODO Auto-generated code

e.printStackTrace();

}

write(WritingQuery query, boolean returnGeneratedKeys, Obect[]params) : xdev.db.WriteResult

●String sql - SQL-Anweisungen die ausgeführt werden sollen. Diese müssen als zusammenhängender SQL-String übergeben werden, z.B. "SELECT * FROM Fahrzeuge".

●VirtualTable vt - Virtuelle Tabelle, die das Abfrageergebnis aufnehmen soll, z.B. Fahrzeuge.VT. Die Virtuelle Tabelle muss im Projekt vorhanden sein. Soll die Virtuelle Tabelle dynamisch erzeugt werden, muss hier null übergeben werden.

●Objekt[ ] params - Hier können Sie bei Bedarf eine Liste zusätzlicher Werte angeben, die via ? Platzhalter in den vorangehenden SQL-String eingefügt werden. Dabei kann es sich um beliebige Datentypen handeln. Dieser Parameter ist optional.

●SELECT select - In Java formulierte SQL-Anweisung für lesenden Zugriff (SQL-Objekt), z.B. für SELECT * FROM Fahrzeuge:

●WritingQuery - In Java formulierte SQL-Anweisung für schreibenden Zugriff (SQL-Objekt).

Hinweis: Die Verwendung von SQL-Strings hat mehrere Nachteile:

1.Die XDEV IDE kann Sie beim Schreiben der SQL-Anweisung nicht durch Autovervollständigung, Syntax-Highlighting, Code-Inspector u.ä. unterstützen.

2.Ob die SQL-Anweisung funktioniert oder nicht, stellt sich erst zur Laufzeit heraus. Die Suche nach der fehlerhaften Codestelle kann aufwändig sein.

3.SQL ist i.d.R. nicht Datenbank-unabhängig. Falls die Anwendung eine andere Datenbank verwenden soll, müssen alle SQL-Anweisungen überprüft und ggf. angepasst werden.