Autor | Thema: SQL-Anweisung bei Feldern mit Leerzeichen in Feldnamen | | Datum:27.02.02 16:17 
(mail@stschnell.de) | |
Hallo Community,
versuche immer noch mit den ASCII-Datenbanken zu arbeiten, wird auch immer besser, bin jedoch auf folgendes Problem gestossen:
SQLExec "INSERT INTO stueli.txt SELECT ´Kennz Baugruppe´ FROM STUECK.TXT WHERE Artikelnummer='999.001.001 '", 2
Dieser Befehl weisst mich auf einen Zirkelbezug in der Select-Liste der Abfragedefinitionen hin????????
Wie kann ich auch Datenfelder in SQL verwenden, die ein Leerzeichen im Feldnamen haben. Habe es bereits mit "" und '', sowie ´´ versucht, jedoch ohne Erfolg.
Danke und Tschüss
Stefan Schnell
|
| | Datum:27.02.02 19:46 
(joerse@gmx.de) | |
Hallo,
Vielleicht funktioniert es mit chr$(34) für die "".
Gruß
Jörg
|
| | Datum:27.02.02 20:29 
(schmidts@flat2serv.de) | |
Hallo,
zunächst mal solltest Du keine Leerzeichen in Datenfeld-Bezeichnungen verwenden (entspricht keiner Namenskonvention, Stichwort: ungarische Notation). Dann ist Deine Klausel vollkommen falsch formuliert, so ist sie richtig:
INSERT INTO tabelle (Feld1, Feld2)
VALUES(Daten1, Daten2)
Mfg.
Sven Schmidts
|
| | Datum:27.02.02 20:59 
(HJKramm@Web.de) | |
nö, die klausel ist so ok ....
"INSERT INTO TEMP_1 SELECT * FROM TEMP_2"
funktioniert prima ......
ODBC kann kürzer sein, als viele glauben ....
besonders wenn die datenbanken den gleichen aufbau haben ....
|
| | Datum:27.02.02 21:27 
(mail@stschnell.de) | |
Hallo Sven,
leider habe ich auf die Datenfeldbezeichnung keinen Einfluss, sie ist durch das ERP-System vorgegeben. Da unser System bereits seit neun Jahren damit arbeitet und auch MS-Query oder MS-Access wunderbar damit zurecht kommen, kann die Namenskonvention so falsch nicht sein (Access klammert sie und Query setzt sie in Hochkommata).
Die Klauses insgesamt ist voll funktionsfähig so, sie übernimmt Datenfelder aus einer Datei. Deine Angabe wäre korrekt, wenn ich Daten direkt eintragen wollte, was ich aber gar nicht vorhabe.
Hallo HJKramm,
mit den Klammern habe ich es schon probiert, leider ohne Erfolg. Mit dem Unterstrich werde ich es morgen mal versuchen, drückt mir die Daumen.
Hallo Jörg,
mit " (@Chr$(34)) habe ich es auch schon versucht, leider auch ohne Erfolg.
Erstmal Danke für Eure Tips, werde am Ball bleiben und, wenn ich Erfolg hatte die Lösung hier publizieren.
Danke und Tschüss
Stefan Schnell
|
| | Datum:27.02.02 20:51 
(HJKramm@Web.de) | |
Uppps, mit ODBC kenn ich mich aus.... aber ASCII-Datenbanken ?
Das ..'.. kann aber nicht funktionieren.
Probier mal [Kennz Baugruppe] oder Kennz_Baugruppe
|
| | Datum:27.02.02 22:17 
(mail@stschnell.de) | |
Kurzer Nachtrag, habe gerade im Watcom SQL gelesen, bezüglich der Feldnamen und dort wird folgendes geäußert:
Column names
A column name is an identifier preceded by an optional correlation name. (A correlation name is usually a table name). If a column name has characters other than letters, digits oder underscore, it must be surrounded by quotation marks ("). For example, the following are valid column names:
student.name
address
"date registered"
"accounts payable"."date paid"
Leider scheint sich jedoch das SQL (welches auch immer via ODBC unter Win verwendet wird) sich leicht zu unterscheiden von irgendwelchen Standards...
|
| | Datum:28.02.02 06:41 
(info@ebs-haase.de) | |
Moin,Moin!
Wenn ein Datenfeld aus einer DB leer ist, dann enthält diese Datenfeld in der Regel NULL.
NULL kann man aber nicht mit " " oder "" abfragen.
Deshalb sollet man den Parameter SQLSETNULL " " verwenden. Hier werden die Inhalte NULL in " " umgewandelt und sind somit abfragbar.
Ich hoffe das hilft weiter.
:-)) Bernd
|
| | Datum:07.03.02 01:59 
(mail@stschnell.de) | |
Hallo Community,
kurz nur zu meinem Resultat:
1. Habe den Feldnamen mit einem Unterstrich (_) versehen, da es wohl offensichtlich nicht möglich ist Feldnamen mit Leerzeichen zu versehen.
2. Nachdem ich 1. so gelöst habe und alle Queries angepasst habe, habe ich ein Stücklistenprogramm via SQLExec programmiert. Leider lässt auch hier die Performance zu wünschen übrig, eine Liste mit 1020 Positionen aus knapp 94000 dauerte ca. 24 Minuten. Nicht akzeptabel für 10 oder mehr geplante Durchläufe.
3. Jetzt bin ich auf Delphi 3 ausgewichen und habe die Algorithmen entsprechende umgesetzt. In den ersten Testläufen benötigte die unter 2 genannte Liste 24 Sekunden (allerdings habe ich vorher einen Index erstellt, der im Speicher die Zugriffe definiert). Wie dem auch sei, dies ist ein tolerables Antwortverhalten (auf jedenfall deutlich schneller als unser ERP-System, und das will ja auch schon was heißen).
Ich will hier kein Plädoyer für Delphi abhalten, habe aber festgestellt, das bei solchen Massen an Daten, wie sie hier verarbeitet werden, ein anderer Ansatz gewählt werden sollte.
Tschüss
Stefan Schnell
|
| | Datum: 07.03.02 10:08 
(schmidts@flat2serv.de) | |
Wir haben in unserer Firma eine Software unter Centura geschrieben (Gupta ist ev. einigen ein Begriff), die nicht gerade die schnellste ist (Interpreter wie Profan²). Wir haben die geschwindigkeitsrelevanten Datenbank-Funktionen auf eine DLL (powered by Delphi) ausgelagert, damit läuft es super.
Sven
PS: Wie ich gesagt habe, die Feldbezeichnungen ;)
|
|
|