Tweet
Seit heut:, bei einem insert kommt die Meldung Tabelle Unkown 204 obwohl diese vorhanden ist ??? Auf verschieden Rechnern !!!
-
-
Hallo Andreas,<br><br>
zeig uns bitte wie Deine Tabellendefinition aussieht und mit welchem SQL-Statement Du diese Tabelle ansprechen möchtest. Verwendest Du eine Dialect 3 Datenbank?<br><br>
Thoma -
Hallo Thomas,
das Problem liegt scheinbar nur bei neu angelgten Tabellen, bei alten gehts noch ?!?
Tabelle anlegen:
CREATE TABLE "amf5"
(
"id" INTEGER,
"name" VARCHAR(20)
);
Inserten:
insert into amf5 (name) values ('test_name');
Auch bekomme ich nun Access voi.... von IBConsole bzw. IBAccess
Ausserdem habe ich IB 6.5, Firebird neu gezogen und installiert unter WIN, immer das selbe :-)
Grüsse
AndreaComment
-
Hallo Thomas,
das Problem liegt scheinbar nur bei neu angelgten Tabellen, bei alten gehts noch ?!?
Tabelle anlegen:
CREATE TABLE "amf5"
(
"id" INTEGER,
"name" VARCHAR(20)
);
Inserten:
insert into amf5 (name) values ('test_name');
Auch bekomme ich nun Access voi.... von IBConsole bzw. IBAccess
Ausserdem habe ich IB 6.5, Firebird neu gezogen und installiert unter WIN, immer das selbe :-)
Grüsse
AndreaComment
-
Hallo Thomas,
scheinbar habe ich auch ein Problem mit dem Forum.
das Problem liegt scheinbar nur bei neu angelgten Tabellen, bei alten gehts noch ?!?
Tabelle anlegen:
CREATE TABLE "amf5"
(
"id" INTEGER,
"name" VARCHAR(20)
);
Inserten:
insert into amf5 (name) values ('test_name');
Auch bekomme ich nun Access voi.... von IBConsole bzw. IBAccess
Ausserdem habe ich IB 6.5, Firebird neu gezogen und installiert unter WIN, immer das selbe :-)
Dialect 3 ist gesetzt
GrüssComment
-
Hallo Andreas,<br><br>
bei einer <b>Dialect 3</b> Datenbank sind Tabellen und Spalten, die mit doppelten Anführungszeichen angelegt werden, <b>case-sensitiv</b>. Verwendest Du den Tabellen-, Spaltennamen in einem SQL-Statement ohne doppelte Anführungszeichen, dann werden diese trotz der Kleinschreibung in Grossbuchstaben umgewandelt. D.h. es ist wichtig auch bei der Verwendung der Tabellen und Spalten die Anführungszeichen zu verwenden, denn nur so werden diese <b>case-sensitiv</b> interpretiert.<br><br>
also: insert into "amf5" ("name") values ('test_name');<br><br>
Ich würde empfehlen, falls nicht unbedingt notwendig (z.B. notwendig bei der Migration von Access nach Interbase) auf case-sensitive Datenbankobjektnamen zu verzichten, da diese in der Regel nur zu Verwirrungen führen ;-).<br><br>
ThomaComment
-
Hallo Thomas,
kaum macht man's wirklich richtig schon gehts, vielen vielen Dank.
Ich hatte mir schon sowas gedacht und auch ausprobiert, aber
scheinbar doch nicht ganz korrekt mit den Anführungszeichen gearbeitet
Deinen Tipp drucke ich ganz groß aus und häng ihn mir an die Wand
AndreaComment
-
Hallo Andreas,<br><br>
mehr Info zum Thema Dialect's in Interbase/Firebird gibt es noch hier http://www.ibphoenix.com/ibp_60_dialect.html<br><br>
Thomas Steinmaurer<br>
http://www.iblogmanager.coComment
-
Hallo Thomas,
danke für die Info, da habe ich gleich noch eine Frage, ist es vermessen mit Interbase und AppServer eine Anwendung mit gleichzeitig
1000 Userconnection zu planen. Ich dachte da an ein Auftrags, Problem Changemanagement mit Inventory usw
AndreaComment
-
Hallo,
>..eine Anwendung mit gleichzeitig 1000 Userconnection zu planen...
diese Anforderung gehört in die Gewichtsklasse der Three-tier-Anwendungen, die einen Datenbankverbindungs-Pool und JITA-Objekte (Just-In-Time-Activation) auf der mittleren Schicht verwenden. Üblicherweise wird dazu eine Maschine mit mehreren CPUs als Datenbankserver eingesetzt (um die Last zu schaffen). Betrachtet man nun die einzelnen Punkte: <br>
a) Rechner mit > 1 CPU<br>
b) Datenbankverbindungs-Pool (OLE DB Provider macht das automatisch) <br>
c) Absolute threadfeste Zugriffswege (zum Beispiel ADO + OLE DB Provider)<br>
bleibt am Ende nur die Empfehlung übrig, <b>nicht</b> zum InterBase zu greifen. Für diese Gewichtsklasse ist der InterBase (zur Zeit) einfach nicht konzipiertComment
-
Hallo Hr. Kosch,
danke für Ihre Antwort, da kommen wir der Sache gleich ein Stückchen näher. CPU Probleme können wir ausschließen ( SunCluster bzw E10K mit mehreren Procs und >2GB RAM). Als DB steht noch Oracle/Unix und MS SQlServer zur Verfügung ( auch in einem HardwareCluster. Als Prio 1 ist die Verfügbarkeit zu sehen (7*24 h). Für mich ist auch noch nich klar nehme ich Delphi (dann nur Windows bzw. TerminalServer) oder JBuilder. Bei der rassanten Entwicklung verliert man leicht den Überblick
Grüsse
AndreaComment
-
Oracle und Delphi alles andere führt an die Wand. Java ist wirklich nicht (noch) für 24*7 konzipiertComment
-
Hallo Andreas 1+2 :-)
bei einer Three-tier-Anwendung hat man es mit verschiedenen Servern zu tun: <br>
1. Maschine (>1 CPU) für die Datenbank (Betriebssystem egal) <br>
2. Maschine (>1 CPU) für die COM+ Objekte (Windows 2000 Server/Advanced Server)<br>
Für ORACLE spricht der Name, für MSSQL2000 die Tatsache, dass hier Betriebssystem + ADO + OLE DB Provider + SQL-Datenbank aus einer Hand ist, und somit die Detail-Probleme (Versionen) geringer sein werden als bei ORACLE. Wenn der Datenbank-Server unter UNIX läuft, erspart das die Qual der Wahl (weil nur ORACLE übrigbleibt).
>Als Prio 1 ist die Verfügbarkeit zu sehen (7*24 h)
Das wird die grösste Hürde für Delphi sein. Delphi 5 (und noch viel stärker Delphi 6) hat mit Problemen auf Mehrprozessor-Rechnern zu kämpfen. Auf der letzten Entwickler-Konferenz bzw. auf den Entwickler-Tagen 2002 habe ich dazu einen drastischen Vergleich vorgestellt (ein typisches COM+-Objekt frisch vom Experten generiert hat gerade einmal 4 Sekunden überlebt). Erst durch den Verzicht auf einen Grossteil der VCL (kein Datenmodul,Webmodul oder ähnliches; keine ADO Express-Komponenten; kein MIDAS/DataSnap) und dem aussschliesslichen Zugriff auf die nativen ADO-Objekte liefen die COM+ Objekt auf dem Applikations-Server so stabil, wie das in dieser Umgebung notwendig ist. Mehrere Bugs der RTL sind seit Mitte 1999 bekannt, wurden bisher aber nicht wirklich korrigiert. Nur mit dem UpdatePack#1 + #2 für Delphi 6 hat sich die Situation geändert (es ist schlimmer geworden)Comment
-
Hallo A*
Ich sollte nicht immer sagen: mit Delphi ist das kein Problemm !!!
Grund für mein Vorhaben ist, daß wir in unserer Firma eine Hand voll Software haben die miteinander arbeiten sollten, das aber nicht tun weil verschiedene Hersteller. Bzw auch nicht die Funktionalität bieten die wir bräuchten, d.h. die Firma wird der Software angepasst.
Das Vorhaben ist auch mein privater Spass, da für so ein Projekt keine Firma Geld in die Hand nimmt (Risiko usw).
Da die Ist-Soll Analyse ca 6-9 Monate dauern wird (bis wirklich alles richtig erfasst ist) haben die BORLANDER ein wenig Zeit die Bugs zu beseitigeComment
-
@ak
>Nur mit dem UpdatePack#1 + #2 für Delphi 6 hat sich die Situation geändert (es ist schlimmer geworden).
Na fein.
Und Oracle nur den Namen hat, oder aber wegen der einen oder anderen Funktionalität auch einen Namen ....
Auf alle Fälle kein InterBase und alles ganz vorsichtig.
p.s. Dieser Thread ist für Träger gleichen Vornamens reserviert. D.hComment
Comment