Re: SQL-Client Problem
Am Montag 20 März 2006 21:17 schrieb Andreas Pakulat:
> On 20.03.06 20:31:06, Sandro Frenzel wrote:
> > Am Montag 20 März 2006 19:37 schrieb Andreas Pakulat:
> > > On 20.03.06 17:16:21, Sandro Frenzel wrote:
> > > > *seufz*...Ich berichtige dich ja nicht gerne, aber MySQL ist für
> > > > reine Datenbanken nicht geeignet, sondern nur für Dynamische
> > > > Webseiten.
> > >
> > > Kannst du das etwas erläutern? Jedenfalls sehe ich kaum einen Grund
> > > McKoi den Vorzug vor MySQL zu geben, vor allem wenn man bedenkt dass
> > > man fuer McKoi erst noch Java installieren muss.
> >
> > Mh, ich wusste, dass du das fragst ;). Naja. Das meinte mein Prof. Das
> > Wieso und Warum ist mir leider in der hochinteressanten Vorlesung
> > entfallen. Aber ich werd ihn gern nochma fragen :P!
>
> Mach das mal. Nicht immer muss der Prof. Recht haben, nur weil er Prof.
> ist ;-) (Womit ich nicht unterstellen moechte das dein Prof. "keine
> Ahnung" hat).
>
> Ich geb gerne zu das MySQL 4.0 und auch 4.1 einige
> wichtige Features vernuenftiger RDBMS' fehlen, aber wir sind
> mittlerweile bei MySQL 5.
>
Oki, vielleicht hab ich auch in aller früh was durcheinander gebracht. Aber
gib mir einfach paar Tage ;)! Schlau siehter ja aus ;) www.tenhagen.org
> > > > Naja, und SQLite hat ja keine grafische Oberfläche.
> > >
> > > Seit wann braucht ein RDBMS eine grafische Oberfläche?
> >
> > In der Tat braucht ein RDBMS keine grafische Oberfläche. Der Client
> > sollte jedoch meiner Meinung nach eine haben.
>
> Warum? Stell dir mal bitte ulogd mit grafischer Oberfläche vor... Es
> kommt immer drauf an, was du mit dem SQL Client machen willst (auch ein
> Addressdaten-GUI ist ein Client). Selbst zum "ausprobieren" von SQL
> Statements braucht man nicht unbedingt eine GUI, solange der
> Kommandozeilen Client eine History hat und evtl. auch Tab-Completion für
> die Kommandos erlaubt (hab ich allerdings noch nicht gesehen) ist das
> bzgl. des Lerneffektes vllt. sogar besser. Ich jedenfalls kann mir Dinge
> besser merken wenn ich sie einmal aufschreibe/eintippe...
>
Naja...da haste schon recht. Aber SQL ist ja vom Prinzip nicht so schwer. Die
paar Befehle merkt man sich schnell. Trotzdem (gerade bei joins) ist eine
automatische Klammerschließung oder weiß der Geier durchaus gemütlich ;)!
> > > > Klar, dass ich dann diesen Fehler nicht bekomme ;)!
> > >
> > > Mist, jetzt hab ich das schon wieder weggeschnitten. Um nochmal auf
> > > meine Aussage zurueckzukommen, dass du kein Problem mit dem SQL Client
> > > hast: Es ging darum dass dein Subject irreführend ist, du hast
> > > tatsaechlich kein Problem mit dem SQL Client, sondern mit AWT in
> > > Verbindung mit deiner Java Runtime. Jedes andere AWT-Programm dass
> > > denselben Code nutzt der bei diesem SQuirrel den Fehler hervorruft
> > > stürzt ebenfalls ab.
> >
> > Also es lag wohl doch an der alten 1.4.2 Version. Hab mir jetzt mal die
> > 1.5 (oder halt 5.0) geladen und es damit probiert.
>
> Aber doch jetzt wohl Sun oder? Meintest du vorher auch Sun? Dann war
> deine Umgebung kaputt oder sonstwas nicht in Ordnung denn dein "java"
> war vom Gij und der hat keine Version 1.4.2, sondern 4.0.x in unstable.
>
Ohje, stimmt. Da hab ich wohl was durchnander gebracht. Also die 1.4.2 war von
Gij und 4.0.x!
Die 1.5 (5.0) ist von Sun, genau. Hab mir jetzt nochmal den -version Schalter
bei beiden bins angeschaut, und da stehts ja eigentlich da =)!
> > leider installiert es die ganzen bins und libs in nem seperaten Ordner,
> > sodass ich jedes mal den absoluten Pfad (statt einfach nur java) zu der
> > neuen "java"-bin Datei angeben muss. Gibt es dafür Abhilfe? Oder kann ich
> > ganz einfach die neuen Dateien ins /usr/bin bzw. /usr/lib Verzeichnis
> > kopieren?
>
> Also doch Sun. Nein du solltest das nicht nach /usr/bin kopieren, du
> solltest java-package installieren und man make-jpkg lesen. Dann
> brauchst du auch gij nicht mehr um Java-Applikationen per APT zu
> installieren.
>
OK, werde ich tun!
Danke dir :)!
Tschau
Sandro.
Reply to: