Qualifizierte Attributnamen?

Tag, meine Damen und Herren,

kann man MySQL durch einen 'Kunstgriff' dazu kriegen, qualifizierte
Attributnamen zu generieren? Also, was ich will, ist z.B.:

Table a = {int b,int c}
Table d = {int e,int f}

Wenn ich nun z.B.

select * from a,d

schreibe, dann werden die Ergebnisspalten b,c,e,f benannt. Das ist
insbesondere Mist, wenn gleichnamige Attribute vorhanden sind. Ich hätte
also gerne a.b, a.c, d.e und d.f und zwar ohne aufwändig

select b AS a.b, c AS a.c, e AS d.e, f AS d.f from a,d

schreiben zu müssen.

Gibt's sowas? Weiß da jemand was?

--
-bm

Re: Qualifizierte Attributnamen?

Bubi Meier schrieb:

> Wenn ich nun z.B.
>
> select * from a,d

"Warum soll ich nicht SELECT * schreiben?"


> schreibe, dann werden die Ergebnisspalten b,c,e,f benannt. Das ist
> insbesondere Mist, wenn gleichnamige Attribute vorhanden sind.

Bei gleichnamigen Spalten (das meinst Du vermutlich mit "Attribute")
wird IMHO der Tabellenname automatisch hinzugefügt. Somit hält sich der
"Mist" in Grenzen.

> select b AS a.b, c AS a.c, e AS d.e, f AS d.f from a,d

Ist Dir

SELECT a.b, a.c, d.e, d.f FROM a, d

zu einfach?

Gruß. Claus

Re: Qualifizierte Attributnamen?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Qualifizierte Attributnamen?

Claus Reibenstein schrieb:
> Bubi Meier schrieb:
>
>> Wenn ich nun z.B.
>>
>> select * from a,d
>
> "Warum soll ich nicht SELECT * schreiben?"
>
>

Ja, schöne Seite. Die genannten Argumente sind allerdings recht
belanglos für mich, da ich den Select Befehl embedded aus Java lostrete
und gedenke die jeweiligen 'Spalten' namenssensitiv auszulesen. Die
Position der Erbegnisspalten ist also irrelevant. Außerdem ist zunächst
sowieso nur ein Einbenutzersystem angedacht.

>> schreibe, dann werden die Ergebnisspalten b,c,e,f benannt. Das ist
>> insbesondere Mist, wenn gleichnamige Attribute vorhanden sind.
>
> Bei gleichnamigen Spalten (das meinst Du vermutlich mit "Attribute")
> wird IMHO der Tabellenname automatisch hinzugefügt. Somit hält sich der
> "Mist" in Grenzen.
>

Das hab ich auch irgendwo gelesen, allerdings funktioniert das so nicht.
Wenn ich hier mal schnell und schmutzig

select * from TKunde,TAuftrag where TAuftrag.RKunde=TKunde.id

schreibe, wobei beide Tabellen eine Spalte namens id haben, werden auch
zwei Ergebnisspalten mit Namen 'id' erzeugt. Im Prinzip ist genau dieser
Umstand auch der Grund meines Anliegens.

Stein des Anstoßes ist so eine abstrakte Reflection class, die dann an
die entsprechenden datenbankkorrespondieren Klassen vererbt wird. Diese
abstrakte Klasse stellt nun Methoden bereit, die aus den vorher
generierten ResultSets die entprechenden (namensgleichen) 'Attribute'
lesen kann. Das Ganze funktioniert auch schon sehr zufriedenstellend,
allerdings nur wenn keine zwei gleichlautenden 'Spalten' in dem
jeweiligen Query vorkommen, was ich etwas 'unvollkommen' finde.

Die MySql Version ist übrigens 5.0.45-community-nt.


>> select b AS a.b, c AS a.c, e AS d.e, f AS d.f from a,d
>
> Ist Dir
>
> SELECT a.b, a.c, d.e, d.f FROM a, d
>
> zu einfach?
>
Nein, zu schwer.

Wenn ich hier

select TKunde.id, TKunde.Vorname, TAuftrag.id from TKunde, TAuftrag

schreibe, sind die Ergebnisspalten übrigens auch nur id, Vorname, id.

--
-bm

Re: Qualifizierte Attributnamen?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Qualifizierte Attributnamen?

Bubi Meier schrieb:

> Claus Reibenstein schrieb:

>> Bei gleichnamigen Spalten (das meinst Du vermutlich mit "Attribute")
>> wird IMHO der Tabellenname automatisch hinzugefügt. Somit hält sich der
>> "Mist" in Grenzen.
>
> Das hab ich auch irgendwo gelesen, allerdings funktioniert das so nicht.

Du hast Recht. Hab's eben mal probiert :-(

>> Ist Dir
>>
>> SELECT a.b, a.c, d.e, d.f FROM a, d
>>
>> zu einfach?
>
> Nein, zu schwer.

*hüstel* ;-)

> Wenn ich hier
>
> select TKunde.id, TKunde.Vorname, TAuftrag.id from TKunde, TAuftrag
>
> schreibe, sind die Ergebnisspalten übrigens auch nur id, Vorname, id.

Auch hier hast Du Recht. Leider :-(

Scheint mir ein Fall für einen Bug-Report zu sein. Oder ist dieses
Verhalten dokumentiert? Ich konnte auf die Schnelle nichts finden.

Gruß. Claus

Re: Qualifizierte Attributnamen?

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Qualifizierte Attributnamen?

Bubi Meier schrieb:


> Das hab ich auch irgendwo gelesen, allerdings funktioniert das so nicht.
> Wenn ich hier mal schnell und schmutzig
>
> select * from TKunde,TAuftrag where TAuftrag.RKunde=TKunde.id
>
> schreibe, wobei beide Tabellen eine Spalte namens id haben, werden auch
> zwei Ergebnisspalten mit Namen 'id' erzeugt. Im Prinzip ist genau dieser
> Umstand auch der Grund meines Anliegens.

Wo genau schreibst Du das? Im Kommandozeilenclient oder im Java-Programm?


> Stein des Anstoßes ist so eine abstrakte Reflection class, die dann an
> die entsprechenden datenbankkorrespondieren Klassen vererbt wird. Diese
> abstrakte Klasse stellt nun Methoden bereit, die aus den vorher
> generierten ResultSets die entprechenden (namensgleichen) 'Attribute'
> lesen kann. Das Ganze funktioniert auch schon sehr zufriedenstellend,
> allerdings nur wenn keine zwei gleichlautenden 'Spalten' in dem
> jeweiligen Query vorkommen, was ich etwas 'unvollkommen' finde.

Kannst Du damit auch den Tabellenamen einer Spalte auslesen? Falls ja,
kannst Du den dazunehmen.


In bezug auf das beschriebene Verhalten hängt es vom verwendeten Client
bzw. API ab, wie die Ergebnisspalten benannt werden. Die C-API erlaubt
für jede Spalte sowohl den Zugriff auf den Tabellen- als auch auf den
Spaltennamen. Was dann das verwendete API daraus macht, ist dieser
überlassen und kann stark variieren.


Nehmen wir mal den Query

| SELECT files.id,sums.id,0 as id FROM files JOIN sums USING (id) LIMIT
| 20

, der vom Kommandozeilenclient so angezeigt wird:

+----+----+----+
| id | id | id |
+----+----+----+
| ... ... ... |

Ist natürlich unschön.


Bei Python-API ist es hingegen so, daß bei einer Namenskollision, wie
sie hier vorliegt, die erste betroffene Spalte behandelt wird wie
gewohnt (also mit unqualifiziertem Namen). Ist ein Name auf diese Weise
bereits vergeben, wird zwecks Unterscheidbarkeit der Tabellenname (der
ggf. auch leer sein kann) und ein "." davorgehängt.
Claus Reibenstein schrieb:

>> Wenn ich hier
>>
>> select TKunde.id, TKunde.Vorname, TAuftrag.id from TKunde, TAuftrag
>>
>> schreibe, sind die Ergebnisspalten übrigens auch nur id, Vorname, id.
>
> Auch hier hast Du Recht. Leider :-(
>
> Scheint mir ein Fall für einen Bug-Report zu sein. Oder ist dieses
> Verhalten dokumentiert? Ich konnte auf die Schnelle nichts finden.

Vermutlich hängt dies vom verwendeten Client/API ab,wie die
Ergebnisspalten benannt werden. Die C-API erlaubt für jede Spalte sowohl
den Zugriff auf den Tabellen- (char *table bzw. char *org_table) als
auch auf den Spaltennamen (char *name bzw. char *org_name im Typen
MYSQL_FIELD bzw. struct st_mysql_field). Was dann das verwendete API
daraus macht, kann stark variieren.


Der Query

| SELECT files.id,sums.id,0 as id FROM files JOIN sums USING (id) LIMIT
| 20

wird vom Kommandozeilenclient so angezeigt:

+----+----+----+
| id | id | id |
+----+----+----+
| ... ... ... |

Bei Python ist es beispielsweise so, daß bei einer Namenskollision der
die erste betroffene Spalte behandelt wird wie gewohnt (also mit
unqualifiziertem Namen). Ist ein Name auf diese Wese bereits vergeben,
wird dann der Tabellenname davorgehängt.

c.execute("")

wirft mir also ein Dict aus mit den Keys id, sums.id und .id. "id" ist
dabei files.id, der, da er der erste ist, behandelt wird, als gäbe es
nur einmal "id". ".id" ist der manuell drangetackerte "0 as id", bei dem
ich einmal sehen wollte, was passiert.


Worauf ich hinauswill: Leider kenne ich mich mit Java so gut wie kaum
aus, aber vielleicht hast Du da ja irgendwie Zugriff auf die
Tabellennamen und kannst anhand derer unterscheiden.


HTH,

Thomas

Re: Qualifizierte Attributnamen?

[Supersedes wegen vergessener Bemerkung zu Bugreport am Ende]

Bubi Meier schrieb:


> Das hab ich auch irgendwo gelesen, allerdings funktioniert das so nicht.
> Wenn ich hier mal schnell und schmutzig
>
> select * from TKunde,TAuftrag where TAuftrag.RKunde=TKunde.id
>
> schreibe, wobei beide Tabellen eine Spalte namens id haben, werden auch
> zwei Ergebnisspalten mit Namen 'id' erzeugt. Im Prinzip ist genau dieser
> Umstand auch der Grund meines Anliegens.

Wo genau schreibst Du das? Im Kommandozeilenclient oder im Java-Programm?


> Stein des Anstoßes ist so eine abstrakte Reflection class, die dann an
> die entsprechenden datenbankkorrespondieren Klassen vererbt wird. Diese
> abstrakte Klasse stellt nun Methoden bereit, die aus den vorher
> generierten ResultSets die entprechenden (namensgleichen) 'Attribute'
> lesen kann. Das Ganze funktioniert auch schon sehr zufriedenstellend,
> allerdings nur wenn keine zwei gleichlautenden 'Spalten' in dem
> jeweiligen Query vorkommen, was ich etwas 'unvollkommen' finde.

Kannst Du damit auch den Tabellenamen einer Spalte auslesen? Falls ja,
kannst Du den dazunehmen.


In bezug auf das beschriebene Verhalten hängt es vom verwendeten Client
bzw. API ab, wie die Ergebnisspalten benannt werden. Die C-API erlaubt
für jede Spalte sowohl den Zugriff auf den Tabellen- als auch auf den
Spaltennamen. Was dann das verwendete API daraus macht, ist dieser
überlassen und kann stark variieren.


Nehmen wir mal den Query

| SELECT files.id,sums.id,0 as id FROM files JOIN sums USING (id) LIMIT
| 20

, der vom Kommandozeilenclient so angezeigt wird:

+----+----+----+
| id | id | id |
+----+----+----+
| ... ... ... |

Ist natürlich unschön.


Bei Python-API ist es hingegen so, daß bei einer Namenskollision, wie
sie hier vorliegt, die erste betroffene Spalte behandelt wird wie
gewohnt (also mit unqualifiziertem Namen). Ist ein Name auf diese Weise
bereits vergeben, wird zwecks Unterscheidbarkeit der Tabellenname (der
ggf. auch leer sein kann) und ein "." davorgehängt.
Claus Reibenstein schrieb:

>> Wenn ich hier
>>
>> select TKunde.id, TKunde.Vorname, TAuftrag.id from TKunde, TAuftrag
>>
>> schreibe, sind die Ergebnisspalten übrigens auch nur id, Vorname, id.
>
> Auch hier hast Du Recht. Leider :-(
>
> Scheint mir ein Fall für einen Bug-Report zu sein. Oder ist dieses
> Verhalten dokumentiert? Ich konnte auf die Schnelle nichts finden.

Vermutlich hängt dies vom verwendeten Client/API ab,wie die
Ergebnisspalten benannt werden. Die C-API erlaubt für jede Spalte sowohl
den Zugriff auf den Tabellen- (char *table bzw. char *org_table) als
auch auf den Spaltennamen (char *name bzw. char *org_name im Typen
MYSQL_FIELD bzw. struct st_mysql_field). Was dann das verwendete API
daraus macht, kann stark variieren.


Der Query

| SELECT files.id,sums.id,0 as id FROM files JOIN sums USING (id) LIMIT
| 20

wird vom Kommandozeilenclient so angezeigt:

+----+----+----+
| id | id | id |
+----+----+----+
| ... ... ... |

Bei Python ist es beispielsweise so, daß bei einer Namenskollision der
die erste betroffene Spalte behandelt wird wie gewohnt (also mit
unqualifiziertem Namen). Ist ein Name auf diese Wese bereits vergeben,
wird dann der Tabellenname davorgehängt.

c.execute("")

wirft mir also ein Dict aus mit den Keys id, sums.id und .id. "id" ist
dabei files.id, der, da er der erste ist, behandelt wird, als gäbe es
nur einmal "id". ".id" ist der manuell drangetackerte "0 as id", bei dem
ich einmal sehen wollte, was passiert.


Worauf ich hinauswill: Leider kenne ich mich mit Java so gut wie kaum
aus, aber vielleicht hast Du da ja irgendwie Zugriff auf die
Tabellennamen und kannst anhand derer unterscheiden. Und wenn ein
Bugreport fällig ist, dann an den Autor der benutzen Java-API - das
C-API ist in der Hinsicht IMHO korrekt - seine Fähigkeiten müßten nur
eben genutzt werden.


HTH,

Thomas

Re: Qualifizierte Attributnamen?

Thomas Rachel schrieb:
> [Supersedes wegen vergessener Bemerkung zu Bugreport am Ende]
>
> Bubi Meier schrieb:
>
>
>> Das hab ich auch irgendwo gelesen, allerdings funktioniert das so nicht.
>> Wenn ich hier mal schnell und schmutzig
>>
>> select * from TKunde,TAuftrag where TAuftrag.RKunde=TKunde.id
>>
>> schreibe, wobei beide Tabellen eine Spalte namens id haben, werden auch
>> zwei Ergebnisspalten mit Namen 'id' erzeugt. Im Prinzip ist genau dieser
>> Umstand auch der Grund meines Anliegens.
>
> Wo genau schreibst Du das? Im Kommandozeilenclient oder im Java-Programm?
>

So wie auch. Ich hoffte, dass das Ergebnis das gleiche ist.

>
>> Stein des Anstoßes ist so eine abstrakte Reflection class, die dann an
>> die entsprechenden datenbankkorrespondieren Klassen vererbt wird. Diese
>> abstrakte Klasse stellt nun Methoden bereit, die aus den vorher
>> generierten ResultSets die entprechenden (namensgleichen) 'Attribute'
>> lesen kann. Das Ganze funktioniert auch schon sehr zufriedenstellend,
>> allerdings nur wenn keine zwei gleichlautenden 'Spalten' in dem
>> jeweiligen Query vorkommen, was ich etwas 'unvollkommen' finde.
>
> Kannst Du damit auch den Tabellenamen einer Spalte auslesen? Falls ja,
> kannst Du den dazunehmen.
>

Also es gibt in Java, wie üblich, eine riesige Klassenbibliothek. Und da
werden in der Klasse ResultSet die z.B. die Methoden getString(String
colName) und viele weitere ähnliche angeboten. Man kann damit, wenn man
ein ResultSet als Ergebnis eines Query ehalten hat, die mit colName
benannte Spalte auslesen. Ich denke mal, dass solche Methoden auch in
anderen Sprachen, bzw. den dazugehörigen Libraries zu finden sind.
Von daher war mir die Sache mit dem * eigentlich egal.

>
> In bezug auf das beschriebene Verhalten hängt es vom verwendeten Client
> bzw. API ab, wie die Ergebnisspalten benannt werden. Die C-API erlaubt
> für jede Spalte sowohl den Zugriff auf den Tabellen- als auch auf den
> Spaltennamen. Was dann das verwendete API daraus macht, ist dieser
> überlassen und kann stark variieren.
>
>
> Nehmen wir mal den Query
>
> | SELECT files.id,sums.id,0 as id FROM files JOIN sums USING (id) LIMIT
> | 20
>
> , der vom Kommandozeilenclient so angezeigt wird:
>
> +----+----+----+
> | id | id | id |
> +----+----+----+
> | ... ... ... |
>
> Ist natürlich unschön.
>
>
> Bei Python-API ist es hingegen so, daß bei einer Namenskollision, wie
> sie hier vorliegt, die erste betroffene Spalte behandelt wird wie
> gewohnt (also mit unqualifiziertem Namen). Ist ein Name auf diese Weise
> bereits vergeben, wird zwecks Unterscheidbarkeit der Tabellenname (der
> ggf. auch leer sein kann) und ein "." davorgehängt.

Das ist hochgradig sinnvoll. Ich dachte eigentlich auch mit meinem
Urposting eine Funktionalität von MySQL in dieser Richtung zu erfahren.
An sich würde ich meinen, dass die Benennung solcher ResultSets, oder
meinetwegen auch Ergenis eines select's, Sache des DBMS ist.
Normalerweise hätte ich angenommen, dass es in MySQL für solche Späße
irgendeine Umgebungsvariable, oder was auch immer, gibt.

> Claus Reibenstein schrieb:
>
>>> Wenn ich hier
>>>
>>> select TKunde.id, TKunde.Vorname, TAuftrag.id from TKunde, TAuftrag
>>>
>>> schreibe, sind die Ergebnisspalten übrigens auch nur id, Vorname, id.
>> Auch hier hast Du Recht. Leider :-(
>>
>> Scheint mir ein Fall für einen Bug-Report zu sein. Oder ist dieses
>> Verhalten dokumentiert? Ich konnte auf die Schnelle nichts finden.
>
> Vermutlich hängt dies vom verwendeten Client/API ab,wie die
> Ergebnisspalten benannt werden. Die C-API erlaubt für jede Spalte sowohl
> den Zugriff auf den Tabellen- (char *table bzw. char *org_table) als
> auch auf den Spaltennamen (char *name bzw. char *org_name im Typen
> MYSQL_FIELD bzw. struct st_mysql_field). Was dann das verwendete API
> daraus macht, kann stark variieren.
>

Also die C-Api würde ich mal in der Java Welt mit dem entsprechenden
jdbc-Datenbanktreiber gleichsetzen wollen. Und diesen jdbc Treiber hab
ich frisch von der mysql Seite. Wobei ich mir allerdings nicht recht
vorstellen kann, dass ein Treiber für EmbeddedSQL die hier diskutierte
Funktionalität leisten kann.



So, nachdem ich nun in meinem Projekt einfach alle 'Spaltennamen' mit
sinnvollen Präfixen versehen habe, plagt mich das nächste Problem:

In einigen Datensätzen soll einige Zeitstatements für allen möglichen
Kram eingetragen werden. Diese habe ich gemäß Manual mit dem Datentyp
'TIMESTAMP' definiert.
In meinen 'Testdaten' habe ich dann ungültige Timestamp mit dem Wert
'00-00-00 00:00:00' belegt. Laut Manual ist dies der offizielle NULL
Wert bei Timestamp. Bei INSERT null wird die derzeitige Systemzeit
eingetragen.
Das Dumme ist, dass in meinem Javaprogramm das ABfragen eines solchen
Wertes zu einer SQL Exception führt. Eine Exception ist ein Fehler.Auch
wenn der Wert einfach als String abgerufen wird, wird eine Exception
ausgelöst, wobei die Meldung 'cannot convert '00-00-00 00:00:00' to
timestamp' ausgegeben wird.

Nun habe ich mal als 'ungültigen' Wert den Wert '1970-01-01 00:00:01'
ausprobiert. Dieser Wert soll laut Manual der erste 'richtige' Wert sein.
Allerdings wird dieser, wie von Geisterhand, zum Wert '1970-01-02
00:00:02' transformiert. Dies geschieht sowohl in der Java Umgebung wie
auch im 'Kommandozeilenmodus'. Merkwürdig, merkwürdig.

-bm


















--
-bm

Re: Qualifizierte Attributnamen?

Bubi Meier wrote:
> Thomas Rachel schrieb:

>> Bei Python-API ist es hingegen so, daß bei einer Namenskollision, wie
>> sie hier vorliegt, die erste betroffene Spalte behandelt wird wie
>> gewohnt (also mit unqualifiziertem Namen). Ist ein Name auf diese Weise
>> bereits vergeben, wird zwecks Unterscheidbarkeit der Tabellenname (der
>> ggf. auch leer sein kann) und ein "." davorgehängt.
>
> Das ist hochgradig sinnvoll. Ich dachte eigentlich auch mit meinem
> Urposting eine Funktionalität von MySQL in dieser Richtung zu erfahren.
> An sich würde ich meinen, dass die Benennung solcher ResultSets, oder
> meinetwegen auch Ergenis eines select's, Sache des DBMS ist.

Nö. Die Benennung der Spalten des Resultsets ist Aufgabe desjenigen,
der die SQL-Query schreibt. Genau und explizit für diesen Zweck sind
Spalten-Aliase in SQL da.

MySQL liefert in den Metadaten des Resultsets alle notwendigen Daten
mit. Ob und wie ein API diese Daten verwendet, ist dann nicht mehr
unbedingt eine Sache von MySQL. Insbesondere ist das Python-API
contributed, steht also nicht unter der Kontrolle von MySQL AB.

Zum Thema Metadaten: der Kommandozeilenclient kennt die -T Option:

~ $mysql -T test
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.0.54 Source distribution

mysql> select t1.id, t2.id, 3 as id from t1, t2;

Field 1: `id`
Catalog: `def`
Database: `test`
Table: `t1`
Org_table: `t1`
Type: LONG
Collation: binary (63)
Length: 11
Max_length: 1
Decimals: 0
Flags: NUM

Field 2: `id`
Catalog: `def`
Database: `test`
Table: `t2`
Org_table: `t2`
Type: LONG
Collation: binary (63)
Length: 11
Max_length: 1
Decimals: 0
Flags: NUM

Field 3: `id`
Catalog: `def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG
Collation: binary (63)
Length: 1
Max_length: 1
Decimals: 0
Flags: NOT_NULL BINARY NUM

+------+------+----+
| id | id | id |
+------+------+----+
| 1 | 2 | 3 |
+------+------+----+
1 row in set (0,00 sec)


siehe auch http://dev.mysql.com/doc/refman/5.0/en/c-api-datatypes.html
unter MYSQL_FIELD.


> Also die C-Api würde ich mal in der Java Welt mit dem entsprechenden
> jdbc-Datenbanktreiber gleichsetzen wollen. Und diesen jdbc Treiber hab
> ich frisch von der mysql Seite. Wobei ich mir allerdings nicht recht
> vorstellen kann, dass ein Treiber für EmbeddedSQL die hier diskutierte
> Funktionalität leisten kann.

Schon der JDBC-Treiber kann nicht beliebige Funktionen bieten, sondern
muß sich an das halten, was JDBC vorsieht.


> In einigen Datensätzen soll einige Zeitstatements für allen möglichen
> Kram eingetragen werden. Diese habe ich gemäß Manual mit dem Datentyp
> 'TIMESTAMP' definiert.
> In meinen 'Testdaten' habe ich dann ungültige Timestamp mit dem Wert
> '00-00-00 00:00:00' belegt. Laut Manual ist dies der offizielle NULL
> Wert bei Timestamp. Bei INSERT null wird die derzeitige Systemzeit
> eingetragen.
> Das Dumme ist, dass in meinem Javaprogramm das ABfragen eines solchen
> Wertes zu einer SQL Exception führt. Eine Exception ist ein Fehler.Auch
> wenn der Wert einfach als String abgerufen wird, wird eine Exception
> ausgelöst, wobei die Meldung 'cannot convert '00-00-00 00:00:00' to
> timestamp' ausgegeben wird.

Dir ist der Unterschied zwischen DATETIME und TIMESTAMP klar? Wenn du
in der Spalte NULLs haben willst, ist TIMESTAMP der falsche Typ.

> Nun habe ich mal als 'ungültigen' Wert den Wert '1970-01-01 00:00:01'
> ausprobiert. Dieser Wert soll laut Manual der erste 'richtige' Wert sein.
> Allerdings wird dieser, wie von Geisterhand, zum Wert '1970-01-02
> 00:00:02' transformiert. Dies geschieht sowohl in der Java Umgebung wie
> auch im 'Kommandozeilenmodus'. Merkwürdig, merkwürdig.

Sagt dir der Begriff "Zeitzone" etwas?


XL

Re: Qualifizierte Attributnamen?

On Mon, 26 Nov 2007 10:40:02 +0100 Axel Schwenke wrote:
> > Nun habe ich mal als 'ungültigen' Wert den Wert '1970-01-01
> > 00:00:01' ausprobiert. Dieser Wert soll laut Manual der erste
> > 'richtige' Wert sein. Allerdings wird dieser, wie von Geisterhand,
> > zum Wert '1970-01-02 00:00:02' transformiert.

> Sagt dir der Begriff "Zeitzone" etwas?

Ein Versatz von 24 Stunden + 1 Sekunde ist allerdings eine ziemlich
interessante Zeitzone.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan wollte von jeher mehr als Happy machen!
(Sloganizer)

Re: Qualifizierte Attributnamen?

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) wrote:
> On Mon, 26 Nov 2007 10:40:02 +0100 Axel Schwenke wrote:
>> > Nun habe ich mal als 'ungültigen' Wert den Wert '1970-01-01
>> > 00:00:01' ausprobiert. Dieser Wert soll laut Manual der erste
>> > 'richtige' Wert sein. Allerdings wird dieser, wie von Geisterhand,
>> > zum Wert '1970-01-02 00:00:02' transformiert.
>
>> Sagt dir der Begriff "Zeitzone" etwas?
>
> Ein Versatz von 24 Stunden + 1 Sekunde ist allerdings eine ziemlich
> interessante Zeitzone.

Mea culpa. Ich habe den Versatz in der Stundenspalte gesehen.
K.A. wer das hier verbosselt, aber ich würde mal auf Java tippen.
Die MySQL-Funktionen UNIX_TIMESTAMP() und FROM_UNIXTIME() haben
zwar auch mit ein paar Merkwürdigkeiten [1] zu kämpfen, machen
solche Fehler aber m.W. nicht.

[1] z.B. weil UNIX Timestamps einen kleineren Wertebereich abdecken
als DATETIME und TIMESTAMP. Oder wegen der Mehrdeutigkeit in
der Sommer/Winterzeit-Umschaltstunde. Siehe Handbuch.


XL