# [SQL, Oracle] Zeile einfügen



## Evolver (10. Aug 2007)

Also ich möchte in folgende Tabelle Zeilen einfügen:

```
CREATE TABLE  "FOLDER" 
   (
	"TABLEKEY" NUMBER(20,0), 
	"ID" VARCHAR2(255) NOT NULL ENABLE, 
	"NAME" VARCHAR2(255), 
	"OWNERFOLDERKEY" NUMBER(20,0), 
	"STATUS" VARCHAR2(6) NOT NULL ENABLE, 
	"EDITOR" VARCHAR2(20), 
	"EDIT_DATE" TIMESTAMP (6), 
	 CHECK (status IN ('INSERT','CHANGE', 'DELETE')) ENABLE, 
	 PRIMARY KEY ("TABLEKEY") ENABLE, 
	 CONSTRAINT "FOLDER_OWNERFOLDERKEY" FOREIGN KEY ("OWNERFOLDERKEY")
	  REFERENCES  "FOLDER" ("TABLEKEY") ENABLE
   )
```

Mein Einfügen könnte z.B. so aussehen:

```
INSERT INTO folder
   (tablekey, id, name, ownerfolderkey, status, editor, edit_date)
   VALUES 3, '2f3da0a0:1144ff979ce:-8000', 'MyMainFolder', NULL, 'INSERT', 'BA', 2007-08-10 15:32:03.671
```


Ich erhalte aber die Fehlermeldung:
_ORA-00947: Anzahl der Werte reicht nicht aus_

Versuche ich das INSERT direkt in der DB über das SQL-Interface einzugeben, werden ich aufgefordert, die "Bind-Variablen" einzugeben (das sind wohl die fehlenden Werte). Was sind diese Bind-Variablen und wie baue ich das in den INSERT-Befehl ein?


----------



## SlaterB (10. Aug 2007)

evtl fehlende Syntax:
statt
VALUES 3, ..
besser
VALUES (3, ..)

überhaupt: teste sowas erst mit EINEM Attribut, dann zwei usw.


----------



## abollm (10. Aug 2007)

Evolver hat gesagt.:
			
		

> Also ich möchte in folgende Tabelle Zeilen einfügen:
> [..]
> Mein Einfügen könnte z.B. so aussehen:
> 
> ...



Gib das folgende INSERT-Statement ein und es wird funktioieren:

```
INSERT INTO folder
(
      tablekey, 
      id, 
      name, 
      ownerfolderkey, 
      status, 
      editor, 
      edit_date
)
VALUES 
(
      3, 
      '2f3da0a0:1144ff979ce:-8000', 
      'MyMainFolder', 
      NULL, 
      'INSERT', 
      'BA', 
      TO_TIMESTAMP_TZ('2007-08-10 15:32:03.671','YYYY-MM-DD HH24:MI:SS.XFF')
)
/
```


----------



## Evolver (10. Aug 2007)

Letzters bring mich dem Ergebnis näher, aber folgender Fehler tritt auf:
_ORA-01830: Datumsformatstruktur endet vor Umwandlung der gesamten Eingabezeichenfolge_


// EDIT: OK, wenn ich das 'X' vor den Sekundenbruchteilen ('FF') weglasse, dann geht es. Wofür steht das X?


----------



## abollm (10. Aug 2007)

Evolver hat gesagt.:
			
		

> [..]
> _ORA-01830: Datumsformatstruktur endet vor Umwandlung der gesamten Eingabezeichenfolge_
> 
> // EDIT: OK, wenn ich das 'X' vor den Sekundenbruchteilen ('FF') weglasse, dann geht es. Wofür steht das X?



X steht gemäß Oracle-Doku für "Local radix character"

Ich hatte auf meiner Oracle 9.2.0.7-Instanz keine Probleme mit dem obigen Statement. Dass du Probleme hattest, liegt vermutlich an deinem NLS_LANG-Parameter. Bei mir ist

american_america.WE8ISO8859P1

eingestellt.


----------



## Evolver (12. Aug 2007)

Hm, gibt es nur diese beiden Möglichkeiten: 
Amerikanisch, mit X
Nicht-Amerikanisch, ohne X

Oder muss man eher sagen, das fehlende X ist eine deutsche (europäische) Spezialität?

===========================

In meine DB-Parametern ist alles auf GERMANY eingestellt. Aber beim Datumsformat sehen die Einstllungen wie folgt aus:
NLS_TIME_FORMAT	HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT	DD.MM.RR HH24:MI:SSXFF
NLS_TIMESTAMP_TZ_FORMAT	DD.MM.RR HH24:MI:SSXFF TZR
NLS_TIME_TZ_FORMAT	HH24:MI:SSXFF TZR

Da kommt überall das X vor, aber eben kein Punkt davor. Wie ist das denn nun genau?


----------



## abollm (12. Aug 2007)

Mea culpa.

Ich hatte bisher mit unterschiedlichen Timezone-Parametern auch noch nicht herumgespielt

Das X steht -- so wie ich es bisher eruieren konnte (insbesondere aus Metalink) -- für den Dezimaltrenner; also in einer deutschen Einstellung für das Komma (,), während die Amerikaner dafür den Punkt (.) nehmen.

Mein Fehler war, dass ich in der folgenden (falschen) Zeile (s. auch oben)


```
TO_TIMESTAMP_TZ('2007-08-10 15:32:03.671','YYYY-MM-DD HH24:MI:SS.XFF')
```

nicht erkannt hatte, dass die ja bereits das X enthält. Somit war der Punkt davor vollkommen überflüssig. Das X ersetzt ja den Punkt! Das ergibt aber bei meinen NLS_LANG-Einstellungen keinen Fehler, während bei GERMAN_GERMANY der vor dir erwähnte Fehler kommt (konnte ich reproduzieren).

Hoffe, dass das nun klar ist. Tur mir leid, wenn ich dich offenbar verwirrt hatte.


----------



## Evolver (12. Aug 2007)

> Somit war der Punkt davor vollkommen überflüssig. Das X ersetzt ja den Punkt! Das ergibt aber bei meinen NLS_LANG-Einstellungen keinen Fehler, während bei GERMAN_GERMANY der vor dir erwähnte Fehler kommt



Gut, also entweder [...]SSXFF oder [...]SS.FF
Sehe ich das jetzt richtig oder gibt es auch noch Alternativen wie [...]SS,FF ?

Ich finde es etwas komisch, dass das X ein allgemeines Trennzeichen (Punkt oder Komma) repräsentiert, aber bei der Sprach-/Formateinstellung _GERMANY_ der Punkt "nicht kompatibel ist" mit dem X.


----------



## abollm (13. Aug 2007)

Evolver hat gesagt.:
			
		

> Gut, also entweder [...]SSXFF oder [...]SS.FF
> Sehe ich das jetzt richtig oder gibt es auch noch Alternativen wie [...]SS,FF ?
> 
> Ich finde es etwas komisch, dass das X ein allgemeines Trennzeichen (Punkt oder Komma) repräsentiert, aber bei der Sprach-/Formateinstellung _GERMANY_ der Punkt "nicht kompatibel ist" mit dem X.



Wie bereits aus dem vorhergehenden Post von mir zu erkennen, stellt X den Platzhalter für das Dezimaltrennzeichen dar. Wenn du aber fest ein Komma vorgeben möchtest, kannst du auf das automatische Erkennen und Einstellen gemäß NLS_LANG-Parameter auch verzichten. Das würde ich aber im professionellen Umfeld grundsätzlich vermeiden.

Du kannst also -- solltest es allerdings grundsätzlich nicht -- so etwas wie folgt machen:

```
TO_TIMESTAMP_TZ('2007-08-10 15:32:12.345','YYYY-MM-DD HH24:MI,SSXFF')
```

Hth


----------

