Allgemeines Datenbankproblem bei SQL Abfrage

[Jens Hartmann]

Hallo mal wieder,

also, ich habe mal wieder ein Problem mit der Datenbankabfrage über SQL. Leider denke ich, das ich da einen Grundlegenden Fehler in meiner Datenbank habe. Ich habe drei neue Tabelle über IBExpert angelegt, kann aber nur auf eine davon zugreifen. Im Anhang, habe ich mal die Fehlermeldung von Delphi.

In der Datenbank existieren momentan 4 Tabellen.

1. Eine Tabelle zum Datenspeichern.
2. Eine Tabelle zum Datenspeichern.
3. Eine Tabelle für die USER-Einstellungen
4. Eine Tabelle für die Konfigurationseinstellung.

Auf 1 und 2 kann ich zugreifen. Ich habe es auch mal im Designmode versucht. Wenn ich im SQL Code folgende Zeilen eingebe, kann ich auf die ersten beiden im Designmode zugreifen und bei den anderen nicht.

SQL-Code:

SELECT * FROM MB256PLUS

Geht...

SQL-Code:

SELECT * FROM MB100

Geht...

SQL-Code:

SELECT * FROM User

Geht nicht...

SQL-Code:

SELECT * FROM Config

Geht auch nicht...


Vieleicht kann mir ja mal jemand sagen, was ich da falsch mache.

Die Datenbank stelle ich mal in den Anhang.

Gruß Jens

[mirage228]

User und Config sind evtl. reservierte Namen innerhalb Deines DBMS...

[quendolineDD]

Ich weiß jetzt nicht, wie es bei Firebird ist. Aber versuch mal <Datenbankname>.Config / <Datenbankname>.User
Eventuell hilft das dann weiter. Ansonsten bleibt dir nichts anderes übrig als deine Tabellen umzubennen.

[RWarnecke]

Sind die Tabellen in 3 und 4 von Dir angelegt worden ?

Edit: Denn User und Config sind reservierte Namen bei Firebird. Probiere die Namen Config und User mal in Anführungszeichen zu setzen. Vielleicht klappt es dann. So habe ich es bei einer Tabellenspalte gemacht, die den Namen Sequence bekommen hat von mir. Sequence ist ebenfalls ein reservierter Name.

[Hansa]

Zitat:

Zitat von mirage228

User und Config sind evtl. reservierte Namen innerhalb Deines DBMS...

So isset. :mrgreen: Ich empfehle einen Textdatei-Editor zum programmieren. Weder das Hightlighting in der DB noch das in IBExpert nützt anscheinend was. :wall:

[mkinzler]

Du könntest die Tabellennamen quoten. Aber besser wäre es diese umzubenennen

SQL-Code:

SELECT * FROM "User";

[Jens Hartmann]

Habe ich jetzt auch gemacht,

das funktioniert auch so jetzt, allerdings habe ich festgestellt, das ich die Tabellen nur dann Abfragen kann wenn ich die durchgehend in Großbuchstaben geschrieben habe.

Tabellenname über IBExpert : 'Benutzer' lässt sich nicht abfragen.

Tabellenname über IBExpert : 'BENUTZER' lässt sich abfragen.

Gruß Jens

[mkinzler]

Durch Quoten wird der name auch casesensitiv. Im IBExpert gibt es dehalb die Option, gequotete Bezeichner automatisch in Großbuchstaben wandeln zu lassen. Ich würde die Tabellennamen aber ändern.

[DeddyH]

Zitat:

Zitat von mkinzler

Ich würde die Tabellennamen aber ändern.

Dazu würde ich aus den genannten Gründen auch dringendst raten, sonst wird man auf Dauer nicht glücklich.

[edit] Ich kaufe ein "d" :mrgreen: Außerdem: http://www.firebirdfaq.org/faq76/ [/edit]

[Hansa]

"Besser" ist eher eine gelinde "Besserung". 8) Man beachte die quotes "". :mrgreen: Das ist wie mit "Made In Germany". Erdacht als Ächtung und heute noch Qualitätssiegel. Als nicht-englisch-Muttersprachler ist es doch wirklich sehr einfach "Benutzer" zu verwenden und den ganzen unnötigen Kram aus dem Weg zu gehen.

Uff, roter Kasten war schneller. :shock: Das Gesagte bleibt. Und die "Quotes" sind echt ein Problem. Es gilt : einmal Quotes immer Quotes ! Der SQL-Dialekt MUSS 3 sein !!

@ roter Kasten 2 : jo.

@ roter Kasten 3 : quotes müssen weg. :mrgreen:

[Jens Hartmann]

Erstmal vielen dank,

ich muss jetzt erstmal meine Hausaufgaben machen. Werde jetzt mal die Einstellungen anpassen, und nochmal die Anleitung zur Firebird lesen.

Zitat:

"Besser" ist eher eine gelinde "Besserung". Man beachte die quotes "". Das ist wie mit "Made In Germany". Erdacht als Ächtung und heute noch Qualitätssiegel. Als nicht-englisch-Muttersprachler ist es doch wirklich sehr einfach "Benutzer" zu verwenden und den ganzen unnötigen Kram aus dem Weg zu gehen.

Wie meinst Du das, ich verstehe ja, das englischen Namen besser sind, aber was meinst Du mit unnötigem Kram?


Gruß Jens

[DeddyH]

Ich hab das so verstanden, dass Du deutsche Bezeichner nehmen sollst, da diese sich mit ziemlicher Sicherheit nicht mit reservierten Bezeichnern beißen.

[alex517]

Hallo Jens,

ich habe es dir bereits hier empfohlen.

Aber nochmal:
Nur Großbuchstaben A..Z, Ziffern 0..9 und den Unterstrich für Feldnamen+Tabellen+Trigger usw. verwenden.
Keine Sonderzeichen oder Umlaute.

Desweiteren keine Standard Keywords / reserved Keywords als Feldnamen+Tabellen+Trigger verwenden.

Du machs dir das Leben damit definitv leichter!

alex

[Hansa]

Zitat:

Zitat von Jens Hartmann

...ich verstehe ja, das englischen Namen besser sind,

Ne, du hast überhaupt nichts verstanden ! Du sollst nicht den englischen allerweltsnamen "User" verwenden, sondern eher "Benutzer" oder, weil englisch gewünscht wird und die Kollision mit englisch reservierten Wörtern anscheinend gewünscht ist, notfalls zumindest "ProgramXYUser". Detaillierter : siehe Alex.

[Jens Hartmann]

Naja, aber jetzt.

ich war bis jetzt der Überzeugung, das man versuche sollte englische Bezeichner zu nehmen. Aber es klingt mir logisch. Englische Bezeichner könnten Belegt sein, und deutsche nicht. Werde jetzt nochmal die ganze Sache überarbeiten.

Hat den mal jemand in die Datenbank reingesehen, und kann mir vieleicht sagen, ob es da sonst noch irgendwelche Sachen gibt, die ich nicht verstanden habe.

Gruß Jens

PS: Danke an alle. Hat mich aufjedenfall nochmal ein bißchen näher ans verstehen der DB´s gebracht.

[Jens Hartmann]

Hallo nochmal,

ich häng mal ne simple Frage zum Thema an. Ich habe auf der IBExpert-Page folgende Anleitung gefunden.

IBExpert Doku

Da ich aber jemand bin der gerne was in Papierform hat, meine Frage, Gibt es diese Anleitung auch irgendwo als PDF oder so.

Ich weiß im Downloadbereich, aber leider nur auf Englisch. Es wäre für mich halt wesendlich einfacher in Deutsch. Vieleicht gibt es da ja irgendwas.

Gruß Jens

[alex517]

Hallo Jens,

meine Empfehlung:

- Tabelle MB100 und MB256PLUS
Feldtyp von Datum als DATE statt CHAR(10)
Feldtyp von Uhrzeit als TIME statt CHAR( 8)


- Tabelle USER umbenennen in BENUTZER
Feld Benutzer umbenennen in BENUTZER_NAME
für BENUTZER_NAME und PASSWORT statt CHAR VARCHAR verwenden

- Tabelle Config umbenennen in KONFIGURATION o.ä.
Feld ID als Primary Key hinzufügen

- SysDatum und SysTime (einmal deutsch einmal englisch!?)
als TIMESTAMP zusammenfassen.

generell:

- wie schon geschrieben, alle Tabellen, Feldname usw in GROSSBUCHSTABEN
ohne Sonderzeichen und keine reservierten oder Keywords (siehe Link).

- ALLE Tabellen sollten eine ein Feld ID als Primary Key besitzen
Diese ID hat, außer einem eindeutigen Wert, grundsätzlich keine Information.
(und ja, es kann Ausnahmen geben, aber nur in Bezug auf den Inhalt)

- Definiere die eigene Domänen.
Wenn du es nicht machst, mach es Firebird für dich automatisch und zwar
für jeder Feld eine eigene (zu sehen in den Systemtabellen).
Damit verringerst du den den Aufwand den Firebird beim Parsen der Statements hat.
Außerden hast du eine bessere Übersicht über deine verwendeten Feldtypen.

Beispiele:

SQL-Code:

  CREATE DOMAIN DOM_BENUTZER AS VARCHAR(40) COLLATE DE_DE; -- eigene Benutzerverwaltung
  CREATE DOMAIN DOM_BLOB AS BLOB SUB_TYPE 0 SEGMENT SIZE 80;
  CREATE DOMAIN DOM_BOOL AS INTEGER DEFAULT 0;
  CREATE DOMAIN DOM_CHAR10 AS CHAR(10) COLLATE DE_DE;
  CREATE DOMAIN DOM_CURRENCY AS NUMERIC(16,4);
  CREATE DOMAIN DOM_DATE AS DATE;
  CREATE DOMAIN DOM_DATETIME AS TIMESTAMP;
  CREATE DOMAIN DOM_ID AS INTEGER NOT NULL;
  CREATE DOMAIN DOM_LINK AS INTEGER NOT NULL;
  CREATE DOMAIN DOM_LINK_LOOSE AS INTEGER;
  CREATE DOMAIN DOM_INT AS INTEGER;
  CREATE DOMAIN DOM_MEMO AS BLOB SUB_TYPE 1 SEGMENT SIZE 80;
  CREATE DOMAIN DOM_NUM9_2 AS NUMERIC(9,2);
  CREATE DOMAIN DOM_PLZ AS CHAR(7) DEFAULT '';
  CREATE DOMAIN DOM_PROZENT AS NUMERIC(9,2);
  CREATE DOMAIN DOM_TIME AS TIME;
  CREATE DOMAIN DOM_VCHAR10 AS VARCHAR(10) COLLATE DE_DE;
  CREATE DOMAIN DOM_VCHAR100 AS VARCHAR(100) COLLATE DE_DE;
  ....

- Boolsche Werte als INTEGER (0/1)

- jede Tabelle bekommt Felder aus denen zu ersehen ist wann und von wem der
Datensatz angelegt und das letzte mal geändert wurde.
Das Eintragen diese Werte erfolgt über Before-Trigger die beim Insert und
Update gefeuert werden. Damit ist allein Firebird bzw. der Rechner aus dem Firebird
läuft für der Inhalt zuständig und nicht irgendein Client-Rechner oder das Programm.
Hilft ungemein beim Interpretieren der Daten, bei der Fehlersuche und
beim "Bewerten" von Kundenaussagen.


Beispiel:
DC, DM sind DOM_DATETIME,
UC, UM sind DOM_BENUTZER

SQL-Code:

CREATE OR ALTER TRIGGER TRIG_TESTTAB_BIU FOR TESTTAB
ACTIVE BEFORE INSERT OR UPDATE POSITION 1
AS
BEGIN

  IF(NEW.ID IS NULL) THEN
    NEW.ID = GEN_ID(GEN_TESTTAB_ID, 1);

  if (inserting) then
  begin
    NEW.DC = current_timestamp;
    NEW.UC = CURRENT_USER;
    /* oder wie bei uns über eine Prozedur wenn nicht mit
       unterschiedlichen Firebird-Usern gearbeitet wird
       EXECUTE PROCEDURE SP_GET_CURRENT_USER RETURNING_VALUES NEW.UC; */
  end

  if (updating) then
  begin
    NEW.DM = current_timestamp;
    NEW.UM = CURRENT_USER;
    /* EXECUTE PROCEDURE SP_GET_CURRENT_USER RETURNING_VALUES NEW.UM; */
  end
END

alex

[alex517]

Zitat:

Zitat von Jens Hartmann

Da ich aber jemand bin der gerne was in Papierform hat, meine Frage, Gibt es diese Anleitung auch irgendwo als PDF oder so.

siehe Bild im Anhang.

Zitat:

Zitat von Jens Hartmann

.. aber leider nur auf Englisch. Es wäre für mich halt wesendlich einfacher in Deutsch.

kann ich nachvollziehen, aber um Englisch wirst du als Softwareentwickler nicht drum rum kommen :wink: .

alex

[Jürgen Thomas]

Kleine Ergänzung zu Alex' Empfehlungen in #17: Inzwischen kennt Firebird den BOOLEAN-Datentyp (ich finde nicht genau, seit welcher Version). Es gibt aber immer wieder einmal ein Problem bei der Anwendung; und intern ist dieser sowieso genauso deklariert wie bei Alex' Vorschlag. Dieser "alte" Vorschlag INTEGER (0/1) (seit Interbase 4.x oder früher) hat also immer noch seine Berechtigung. Jürgen

[Jens Hartmann]

Zitat:

siehe Bild im Anhang.

Danke Alex,
hatte ich gesehen, ist halt nur echt aufwendig die ganze Page zu drucken.

Zitat:

kann ich nachvollziehen, aber um Englisch wirst du als Softwareentwickler nicht drum rum kommen .

Ich weiß, ist halt nur nicht so einfach.
Naja, vieleicht versuch ich es mal mit der Englischen Anleitung. Das Problem ist halt bei mir auch die Zeit. Ich habe mal angefangen zu programmieren, als ich den Techniker gemacht habe, es hat mir Spaß gemacht, und ich habe angefangen eine Software für unser Unternehmen zu schreiben. Dadurch, das es halt mittlerweile eingesetzt werden soll, muss ich mich halt intensiver damit befassen. Das versuche ich halt. Und da ist natürlich Englisch für mich ziemlich Zeitintensiv.

Trotzdem, danke für deine antworten. :thumb: Werde die mal durcharbeiten. Einige Sachen habe ich gestern schon angepasst.

Zitat:

- Tabelle MB100 und MB256PLUS
Feldtyp von Datum als DATE statt CHAR(10)
Feldtyp von Uhrzeit als TIME statt CHAR(10)

Weiß nicht ob das richtig wäre, weil mir dieses als String geliefert wird, und ich diesen ja sonst umwandeln müsste. Deshalb, hatte ich zusätzlich die Felder SysDatum (SystemDatum) und SysTime (SystemZeit) eingefügt.

Gruß Jens

[Hansa]

Zitat:

Zitat von Jens Hartmann

.. ist halt nur echt aufwendig die ganze Page zu drucken..

Dann kaufe dir das bereits gedruckte IBExpert-Book. 8) Und englisch ? Nun ja, schon blöd, wenn man das nicht lesen kann. Wer sich allerdings die Mühe macht, seine eigenen Bezeichner auf englisch zu übersetzen, der sollte auch mit den Begriffen (Table=Tabelle) (Database=Datenbank) etc. zurechtkommen. Computerenglisch lesen ist jedenfalls wesentlich einfacher, als z.B. mit Bush in Texas zu reden. :mrgreen:

[alex517]

falls du diese Daten auswerten willst ist es auf jeden Fall sinnvoll.
Die Umwandlung solltes du im Delphi-Programm machen und die Werte über

Delphi-Quellcode:

MyDataSet.ParamByName('DATUM').AsDate := ..
MyDataSet.ParamByName('UHRZEIT').AsTime := ..

setzten. Damit ist das korrekte Eintragen gewährleistet.
Zusätzlich könnte man den von Gerät für das Ereignis gelieferten String als
Original in einem VARCHAR oder Blob speichern um bei evtuellen Problemen darauf
zugreifen zu können.
alex

[Jens Hartmann]

Zitat:

Dann kaufe dir das bereits gedruckte IBExpert-Book. Und englisch ? Nun ja, schon blöd, wenn man das nicht lesen kann. Wer sich allerdings die Mühe macht, seine eigenen Bezeichner auf englisch zu übersetzen, der sollte auch mit den Begriffen (Table=Tabelle) (Database=Datenbank) etc. zurechtkommen. Computerenglisch lesen ist jedenfalls wesentlich einfacher, als z.B. mit Bush in Texas zu reden.

Ach Hansa, bist echt en netter Typ.

Weißt Du, ich habe genau aus dem Grund (weil ich davon ausgegangen bin, das man englisch verwenden sollte) z.B. USER genommen statt BENUTZER. Es ist auch nicht so, das ich Table und Database nicht übersetzt bekomme. Ich bekomme es auch hin einen ganz Text zu lesen. Es ist nur einfacher, für mich in Deutsch , weil ich halt einen Text in englisch nicht fehlerfrei und schnell lesen kann.
Außerdem, ist aller Anfang schwer, und die ganzen Informationen zu sortieren, zu verstehen und anschließende Fehlerfrei umzusetzten, ist halt nicht einfach. Und dafür, das ich das Thema nicht beruflich mache, denke ich bin ich schon echt weitgekommen.
Und wenn es da ein Buch zu IBExpert und Firebird in Deutsch gibt, bin ich auch bereit sowas zu kaufen und zu lesen.
Ich hoffe Du kannst mich wenigstens ein wenig verstehen, auch wenn wir zwei schon öfters verschiedener Ansichten waren.

Trotzdem Gruß Jens

[Jens Hartmann]

Zitat:

falls du diese Daten auswerten willst ist es auf jeden Fall sinnvoll.
Die Umwandlung solltes du im Delphi-Programm machen und die Werte über
Delphi-Quellcode: markieren
MyDataSet.ParamByName('DATUM').AsDate := ..
MyDataSet.ParamByName('UHRZEIT').AsTime := ..


setzten. Damit ist das korrekte Eintragen gewährleistet.
Zusätzlich könnte man den von Gerät für das Ereignis gelieferten String als
Original in einem VARCHAR oder Blob speichern um bei evtuellen Problemen darauf
zugreifen zu können.

Alles klar, werde ich mal angehen und versuchen umzusetzten.

Gruß Jens

[hoika]

Hallo,

noch zum Datum.
Falls die Nutzer mal eine Einschränkung wollen,
z.B. die Daten eines Monats, geht das per Extract mit einem Date
viel viel einfacher als mit einem String.


Heiko

[Jens Hartmann]

Zitat:

Falls die Nutzer mal eine Einschränkung wollen,
z.B. die Daten eines Monats, geht das per Extract mit einem Date viel viel einfacher als mit einem String.

Das ist aufjedenfall ein guter Grund, weil ich genau das benötige, und momentan den String prüfe. Funktioniert zwar, ich hatte mir aber schon gedacht, das man das besser lösen kann. Werde ich mir also umgehend anschauen.

Das sind alles so Aufgabe, die ich mir gesetzt habe, wenn ich das Programm soweit fertig habe, den Code zu optimieren, was man aber jetzt schon machen kann, sollte man auch tun. Daher werde ich mich heute direkt an Eure Vorschläge geben.

Gruß Jens

[Jens Hartmann]

Zitat:

- jede Tabelle bekommt Felder aus denen zu ersehen ist wann und von wem der
Datensatz angelegt und das letzte mal geändert wurde.

Ich denke, das ich das nur für die Systemtabellen benötige, um nachvollziehen zu können, wer und wann, was an den Einstellungen geändert worden ist. Die Ereignistabellen, werden automatisch durch Daten der COM-Schnittstelle beschrieben, und dürfen garnicht erst durch den USER geändert werden.

Zitat:

Das Eintragen diese Werte erfolgt über Before-Trigger die beim Insert und
Update gefeuert werden. Damit ist allein Firebird bzw. der Rechner aus dem Firebird
läuft für der Inhalt zuständig und nicht irgendein Client-Rechner oder das Programm.
Hilft ungemein beim Interpretieren der Daten, bei der Fehlersuche und
beim "Bewerten" von Kundenaussagen.


Beispiel:
DC, DM sind DOM_DATETIME,
UC, UM sind DOM_BENUTZER

Allerdings, habe ich das noch nicht so ganz verstanden. Wenn ich es verstanden habe, bedeutet das, über die im Beispiel erstellte Routine, wird durch die Firebird, automatisch die Zeit und der Benutzername in die jeweilige Tabelle eingetrage. Das heißt, das sind aber dann die Benutzer die gerade an der Datenbank angemeldet sind. Das heißt, da ich momentan noch mit den Standartwerten SYSDBA/masterkey arbeite, würde immer dieser eingetragen. Was dann bedeuten würde, das ich jedem Programmnutzer, auch einen Datenbankzugang einrichten müsste, der dann eingetragen werden könnte.

Im Anhang, habe ich übrigens mal die geänderte Datenbank, vieleicht kann mir ja mal jemand sagen, ob das jetzt besser aussieht.

Gruß Jens

[alex517]

Hallo Jens,

- Bevor du etwas anders macht, leg einen neuen Firebird-User an und erstelle deine Datenbank
mit diesem neuen User als Owner. Also weg von SYSDBA/masterkey.
Das wird dir Probleme beim Kunden ersparen. Und der nachträgliche Umstieg ist nicht ganz trivial.

Zitat:

Wenn ich es verstanden habe, bedeutet das, über die im Beispiel erstellte Routine, wird durch die Firebird, automatisch die Zeit und der Benutzername in die jeweilige Tabelle eingetrage. Das heißt, das sind aber dann die Benutzer die gerade an der Datenbank angemeldet sind. Das heißt, da ich momentan noch mit den Standartwerten SYSDBA/masterkey arbeite, würde immer dieser eingetragen. Was dann bedeuten würde, das ich jedem Programmnutzer, auch einen Datenbankzugang einrichten müsste, der dann eingetragen werden könnte.

Du kannst beim Connect deines Programm zur Datenbank deine selbst verwalteten Benutzernamen
in einer "Context Variable" hinterlegen. Wenn du das im Context der Session machst,
steht diese Variablen solange zur Verfügung wie die Connection besteht.
Diese Variable kannst du dann im Trigger abfragen und in das entsprechende Datenfeld eintragen.
Damit muss nicht jeder Benutzer einen eigenen Datenbankzugang haben.
Siehe auch hier.

- Für die ID solltest du so wie für alle anderen Felder eine Domäne anlegen,
die außerdem Not NULL sein sollte.

- Je nach gewünschter Auswertung wirst du später noch Indizes anlegen müssen um die
Abfragen entsprechend performant zu gestallten.

alex

[Jens Hartmann]

Hallo Alex,

werde jetzt erstmal diese Sachen versuchen umzusetzen.

alex hat geschrieben:

Zitat:

- Für die ID solltest du so wie für alle anderen Felder eine Domäne anlegen,
die außerdem Not NULL sein sollte.

[FRAGE]wie bekommt man eigendlich das 'alex hat geschrieben' an die Stelle von Zitat:[FRAGE ENDE]

Für das Feld ID hatte ich eine Domäne angelegt, konnte diese allerdings, nicht ändern, da das Feld der Primärschlüssel ist, und IBExpert kein Commit zugelassen hat.

Danke für die freundliche Hilfe

Gruß Jens

[Jürgen Thomas]

Zitat:

Zitat von Jens Hartmann

[FRAGE]wie bekommt man eigendlich das 'alex hat geschrieben' an die Stelle von Zitat:[FRAGE ENDE]

Ausprobieren: Drücke vor der nächsten Antwort auf den Zitat-Button; dann wird es dir vorbereitet mit quote-Tags, Gleichheitszeichen und Autor in Gänsefüßchen.

An manchen Stellen ist IBExpert in der Tat sehr restriktiv. Aber gerade den PK kannst du doch relativ einfach ausschalten, dann die Domain ändern und danach den PK neu setzen.

Gruß Jürgen

[Jens Hartmann]

Zitat:

Zitat von Jürgen

An manchen Stellen ist IBExpert in der Tat sehr restriktiv. Aber gerade den PK kannst du doch relativ einfach ausschalten, dann die Domain ändern und danach den PK neu setzen.

Das dachte ich auch, aber ich muss den PK auf eine anderes Feld legen. einfach ausschalten Funtz irgendwie nicht. Das wäre zwar jetzt auch kein Problem, ist aber wahrscheinlich nicht ganz der richtige Weg.

Gruß Jens

[ZITAT, Geht ja]

[alex517]

PK löschen, Domäne ändern, PK neu anlegen.

[Jens Hartmann]

Das hab ich jetzt gemacht, und es geht auch. Den Rest werde ich heute abend und morgen mal testen und meine DB umbauen. Das mit dem User und so.

Also Danke schon

Gruß Jens :thumb:

[Jens Hartmann]

Hallo nochmal,

habe das mit den USER Einstellungen für Firebird jetzt alles hinbekommen. Habe dann in IBExpert, meine Datenbankregitrierung auch mal auf meinen neuen USER umgestellt, und ich bekomme auch Connection.
Dann habe ich allerdings nicht mehr die Möglichkeit unter Tabellen, mir die vorhanden Daten anzusehen.
Das ist ein Problem bei Tabellen, in den ich Einstellungsparameter bereitstellen möchte, weil ich die ja mit gewissen Vorgaben fertig zur Verfügung stellen will.

Mache ich das jetzt in der Domäne mit den Einstellungen Default für jede Spalte, oder melde ich mich bei IBExpert mit SYSDBA an.

Gruß Jens

[mkinzler]

Du musst die entsprechenden Rechte für dein neuen Benutzer setzen (GRANT)