Tabellen verbinden

[hoika]

Hallo,
bitte noch einmal

Zitat:

Am Besten mal die Abfrage unabhängig von FastReports ausführen.

Ausserdem wäre es besser, beim Order By über die p.id zu gehen
order by
p.id;
weil die u.user_id ja NULL sein könnte

[Schuby]

Gleicher Fehler.. unabhängig von FastReports gemacht.

Delphi-Quellcode:

select
    p.*, u.user_id
from
    person p LEFT OUTER JOIN urlaub u ON u.user_id = p.id
order by
    p.id;

Fehler -> Im Ausdruck stimmt ein Datentyp nicht überein



Frage ? Kann es sein weil Table1 person.id ein Counter ist ?



mfg

[jobo]

Wenn ungewöhnliche Daten angezeigt werden und scheinbar alles stimmt, einfach mal einzeln selektieren und alles ausgeben, auch die vermeintlich gesetzten ID.

also

Code:

select * from person

und

Code:

select * from urlaub

auch nicht schlecht wäre von beiden Tabellen das Create Statement anzuzeigen / abzufragen.

Deine Frage kannst Du selber am besten beantworten, solange Du nicht den Tabellenaufbau zeigst.

"Counter" beschreibt vermutlich ein Verhalten , nicht unbedingt einen Datentyp.

[Schuby]

FastReport lasse ich erstmal links liegen.

Ich habe mir ADOQuery / mit einen DBGrid erstellt das ich sehe was passiert.

select * from person //ok wird angezeigt
select * from urlaub //ok wird angezeigt

Delphi-Quellcode:

Procedure TForm1.Table1_erstellen;
const
 cCRLF = #13#10;
 cCreateDaten =   'CREATE TABLE person(' + cCRLF
 + 'Id             counter,'                 + cCRLF   //
 + 'datum       varchar(10),'                + cCRLF   //
 + 'name        varchar(20),'                + cCRLF   //
 usw.....

Das meinte ich mit id, weil es ein Counter ist


mfg

[jobo]

Counter ist eine realtiv ungewöhnliche Bezeichnung.

Man nennt das normalerweise Autoincrement. Aber bei ACCESS ist vieles nicht Standard.
Counter ist vielleicht ein INT, du kannst selbst versuchen herauszufinden, welcher Datentyp wirklich hinter dem Typ Counter steckt.
Entsprechend sollten die Referenzwerte in anderen Tabellen dann halt auch vom Typ INT sein.

Eigentlich würde ich erwarten, dass auch ACCESS es nicht so genau nimmt, wenn es auf der einen Seite INT ist und auf der anderen meinetwegen BIGINT, aber vielleicht hast Du ja versehentlich ein CHAR oder DATE genommen.

Und wegen des 'vielleicht' nochmal der Hinweis:
Viele dieser Fehler sind reine Flüchtigkeitsfehler, solange Du nicht im Klartext zeigst, was da steht, muss ich erfahrungsgemäß befürchten, dass das gar nicht da steht. Du schreibst halt im Zweifel nur das, was Du selbst glaubst, dass es da stünde.

Deshalb macht man es gern so, dass man 1:1 hinschreibt, was das Problem bereitet, echter Code, echte Daten und wie der Fehler lautet. So kann es jeder per Copy Paste nachvollziehen.

[Jasocul]

Die Definition der zweiten Tabelle fehlt noch. Nur dann kann man sehen, warum beim SQL gemeckert wird.
Counter entspricht in Access dem Typ Long, wenn ich mich richtig erinnere.

Abgesehen davon:

Zitat von Schuby:

+ 'datum varchar(10),' + cCRLF //

Ich hoffe, du musst nie nach dem Datum sortieren. Das wird nämlich mit dem Typ varchar für das Datum nicht funktionieren. Ich weiß nicht welcher das bei Access genau ist, aber ich meine "Date" oder "DateTime".