MySQL-Problem mit Stringvergleich

    MySQL-Problem mit Stringvergleich

    Hallo Zusammen,

    ich hänge gerade an einem Problem mit MySQL.
    Ich erzeuge mit

    Delphi-Code

    1. qWork.SQL.Add(
    2. ' INSERT INTO' + sLineBreak
    3. + ' zugriff' + sLineBreak
    4. + ' (' + sLineBreak
    5. + ' projekt_id,' + sLineBreak
    6. + ' benutzer_id,' + sLineBreak
    7. + ' datei_name' + sLineBreak
    8. + ' ) VALUES (' + sLineBreak
    9. + IntToStr(iProjektID) + ',' + sLineBreak
    10. + IntToStr(iBenutzerID) + ',' + sLineBreak
    11. + ' :TheFileName ' + sLineBreak
    12. + ' )'
    13. );
    14. qWork.ParamByName('TheFileName').AsString := sQuellDatei;
    15. qWork.ExecSQL();

    einen Datensatz.
    Und mit

    Delphi-Code

    1. qWork.SQL.Add(
    2. ' SELECT' + sLineBreak
    3. + ' *' + sLineBreak
    4. + ' FROM' + sLineBreak
    5. + ' zugriff' + sLineBreak
    6. + ' WHERE' + sLineBreak
    7. + ' (projekt_id = ' + IntToStr(iProjektID) + ') AND' + sLineBreak
    8. + ' (LCASE(datei_name) = :ThePfad )'
    9. );
    10. qWork.ParamByName('ThePfad').AsString := AnsiLowerCase(sQuelldatei);
    11. qWork.Open();
    12. iAnzahl := qWork.RecordCount;

    versuche ich den gleichen Datensatz wieder zu finden.
    Allerdings klappt dies nicht. Wenn ich die Such-SQL über HeidiSQL ausführe, muss ich den Text selbst noch
    Quoten (logisch) und weil Dateinamen einen Backslash haben (Ist nur der relative Pfad "pas\main.pas" oder "pas\Projekt\ProjektTools.pas")
    diesen Backslash auch noch C-conform wandeln.
    Also

    Quellcode

    1. LCASE(datei_name) = 'pas\\main.pas'


    Vielleicht hilft auch diese Info: In HeidiSQL zeigt er mir für den CreateCode der Tabelle folgendes an:

    Quellcode

    1. CREATE TABLE `zugriff` (
    2. `id` INT(11) NOT NULL AUTO_INCREMENT,
    3. `projekt_id` INT(11) NULL DEFAULT NULL,
    4. `benutzer_id` INT(11) NULL DEFAULT NULL,
    5. `datei_name` LONGBLOB NULL,
    6. PRIMARY KEY (`id`),
    7. UNIQUE INDEX `idx_id` (`id`),
    8. INDEX `idx_projekt_id` (`projekt_id`)
    9. )
    10. COLLATE='utf8_general_ci'
    11. ENGINE=MyISAM
    12. AUTO_INCREMENT=4
    13. ;

    Wobei das Auto_increment dadurch kommt, dass ich derzeit 3 Datensätze (zum Testen) habe.
    Ich wollte für "ftBlob" und "ftMemo" in dem Script für das Anlegen der Datenbank immer "LONGBLOB" nehmen,
    aber "LONGTEXT" scheint auch nicht besser zu funktionieren.

    Ich sehe einfach nicht, warum ich als RecordCount immer 0 bekomme. Ich dachte auch, dass "ParamByName" sich um alles kümmert.
    Und wenn ich das manuell Quote (qWork.ParamByName('ThePfad').AsString := AnsiLowerCase(AnsiReplaceStr(sQuelldatei, '\', '\\'));
    Anders herum: Beim Insert funktioniert es ja. Hoffendlich ist es nur ein kleiner Tippfehler und ich seh' den einfach nur nicht! *hoff*

    Vielen Dank auf jeden Fall schonmal für's lesen!

    MfG
    Incocnito
    Moin... 8o
    Hier muß ich mal weit ausholen. Nicht böse sein... 8o

    Ich vermute das du den Verleich des Ordners case insensitiv haben möchtest. Gut.

    1. Dein Problem:
    -> COLLATE='utf8_general_ci'
    Vergleich mit
    -> AnsiLowerCase(sQuelldatei)
    ...paßt nicht. 8)

    Lösung1 (Besser):

    Delphi-Code

    1. + ' (LCASE(datei_name) = LCASE(:ThePfad) )'
    2. );
    3. qWork.ParamByName('ThePfad').AsString :=sQuelldatei;

    Lösung2:

    Delphi-Code

    1. qWork.ParamByName('ThePfad').AsString := LowerCase(sQuelldatei);


    Datenbank:
    `datei_name` LONGBLOB NULL, -> besser für Text `datei_name` TEXT (bis 65000 Zeichen)

    Frage:
    und weil Dateinamen einen Backslash haben (Ist nur der relative Pfad "pas\main.pas" oder "pas\Projekt\ProjektTools.pas")
    diesen Backslash auch noch C-conform wandeln.

    ...das verstehe ich nicht, Text ist Text. ?(

    Hinweis:
    Hast du schon mal den Begriff SQL Injection gehört? Dein SQL ist anfällig dafür. :/
    de.wikipedia.org/wiki/SQL-Injection

    Delphi-Code

    1. + ' ) VALUES (' + sLineBreak
    2. + IntToStr(iProjektID) + ',' + sLineBreak // kein Parameter
    3. + IntToStr(iBenutzerID) + ',' + sLineBreak // kein Parameter
    4. + ':TheFileName' + sLineBreak
    5. + ' )'
    6. );
    7. qWork.ParamByName('TheFileName').AsString := sQuellDatei;
    8. qWork.ExecSQL();

    Delphi-Code

    1. + ' ) VALUES (' + sLineBreak
    2. + ':PID' + ',' + sLineBreak // mit Parameter
    3. + ':BID' + ',' + sLineBreak // mit Parameter
    4. + ':TheFileName' + sLineBreak
    5. + ')'
    6. );
    7. qWork.ParamByName('TheFileName').AsString := sQuellDatei;
    8. qWork.ParamByName('PID').AsInteger := iProjektID;
    9. qWork.ParamByName('BID').AsInteger := iBenutzerID;
    10. qWork.ExecSQL();


    Hinweis1:
    8)
    Es gibt andere Varianten das SQL abzulegen. Deine Variante (Add + + + + ExecSql) funktioniert, ist aber nicht wirklich testbar. Die bessere Variante ist imho die Speicherung in Ressourcen. Die SQL werden mit einkompilliert, liegen aber als SQL File außerhalb vom Quelltext im Original vor und liegen damit auch im Versionskontrollsystem. Damit sind sie direkt in HeidiSQL testbar. :thumbsup:
    Tutorial für das Prinzip:
    delphipraxis.net/49505-sql-dat…s-resource-einbinden.html
    Tool für die Verwaltung:
    delphipraxis.net/190316-dimowa%AE-sql-resource-creator.html

    Hinweis2:
    Ich vermute mal das du von der alten Schule bist und deshalb die ungarische Notation anwendest. :) Da sagt der Styleguide des DelphiTreffs dazu...
    Delphi stammt aus Kalifornien, weshalb wir von der Ungarischen Notation abraten

    delphi-treff.de/object-pascal/styleguide/

    Hinweis3:

    Bitte hinterlege bitte deine Delphi Version in deinem Profil. Da müssen wir nicht raten. Danke. :)

    ...viel Spaß. :thumbup:

    Dieser Beitrag wurde bereits 9 mal editiert, zuletzt von „haentschman“ ()

    Hi Zusammen,

    haentschman schrieb:


    Lösung1 (Besser):

    Delphi-Code

    1. + ' (LCASE(datei_name) = LCASE(:ThePfad) )'
    2. ...
    3. qWork.ParamByName('ThePfad').AsString :=sQuelldatei;


    Gelöst bekommen habe ich es schließlich mit dem oben und der Umstellung auf InnoDB als ENGINE-Typ.
    Das mit den Zeichensätzen verstehe ich leider nicht so recht. Ich bekomme den Pfad aus dem Delphi-Fenster (Stil "Klassisch nicht angedockt")
    über die Windows-Funktionen

    Delphi-Code

    1. iByteLen := (iLen * SizeOf(Char)) + 1; // nur 1 null-char
    2. pWndCaption := GetMemory(iByteLen);
    3. SendMessageW(iCurrHld, WM_GETTEXT, iByteLen, Integer(pWndCaption));
    4. SetLength(sTempTitle, iLen);
    5. Move(pWndCaption^, sTempTitle[1], iByteLen - 1);
    6. Procs[iProcPos].FensterListe[iFensterPos].sTitle := sTempTitle;
    7. FreeMemory(pWndCaption);

    da weiß ich schon nicht welcher Zeichensatz das ist. Irgendwie landet es ja in sTitle (einem "klassischen" String).
    Ab und zu wandelt Delphi ja was selbst (PChar -> String -> WideString -> was-auch-immer) oder auch nicht,
    da brauch ich echt nochmal eine Schulung, aber ich glaube sowas müsste schon persönlich sein.
    Wie dass dann noch zum TMyQuery-Aufruf passt und ob da was formatiert/konvertiert werden muss ... ist mir bei weitem zu Hoch.
    Auch das Auslesen der Fenstertitel war deswegen mehr try-and-error und weit weg von zielgerichteter Arbeit.
    Um das alles zu verstehen müsste man schon wissen, wie das auf Byteebene hintenrum funktioniert ... also
    ich müsste sowas zumindest wissen, damit ich das verstehe. :( ?(
    Alleine wenn ich an den move-Befehl denke wird mir ganz schummerig:

    Quellcode

    1. Move(pWndCaption^, sTempTitle[1], iByteLen - 1);

    oder

    Quellcode

    1. Move(@pWndCaption, sTempTitle[1], iByteLen - 1);

    oder

    Quellcode

    1. Move(pWndCaption^, @sTempTitle, iByteLen - 1);

    oder

    Quellcode

    1. Move(pWndCaption, sTempTitle^, iByteLen - 1);

    oder

    Quellcode

    1. Move(pWndCaption^, sTempTitle[1], iByteLen + 1);

    und zwischendurch hatte ich trollo sogar noch irgendwas mit "sTempTiltle[0]"! Ganz mal daneben! :S

    haentschman schrieb:


    Hast du schon mal den Begriff SQL Injection gehört? Dein SQL ist anfällig dafür.

    Gehört ja, aber ich verstehe nicht, wie ich mit einem Integer eine SQL-Injection machen können sollte. ?(

    haentschman schrieb:


    ...das verstehe ich nicht, Text ist Text.

    Ich musste in HeidiSQL, wenn ich "von Hand" gesucht habe sowas schreiben wie

    Quellcode

    1. where datei_name = 'pas\\main.pas'

    In der Hilfe von MySQL hatte ich glücklicherweise gefunden, dass die Texte, welche als Text eingefügt werden C-konform sein müssen.
    Damit hatte ich dann auch das erwartete Ergebnis. ^^

    haentschman schrieb:


    Bitte hinterlege bitte deine Delphi Version in deinem Profil. Da müssen wir nicht raten. Danke.

    Erledigt. Ich hoffe aber, dass meine Anwendung (bis zu einem bestimmten Grad) reletiv übergreifend funktioniert.
    Zumindestens sehe ich spontan kein Konstrukt, welches es nicht schon in delphi 6 oder so gab! :saint:

    Auf jeden Fall vielen lieben Dank für die Tipps!

    MfG
    Incocnito
    Hallöle... 8)
    Auf jeden Fall vielen lieben Dank für die Tipps!

    ...gern geschehen.

    Gehört ja, aber ich verstehe nicht, wie ich mit einem Integer eine SQL-Injection machen können sollte.

    siehe Bild aus dem Wiki. Im Prinzip kannst du dem Integer, der als Text übertragen wird, eine Anweisung anhängen und die Datenbank manipulieren. Mit Parametern passiert das nicht. :thumbup:

    Gelöst bekommen habe ich es schließlich mit dem oben und der Umstellung auf InnoDB als ENGINE-Typ.

    ...imho ist MyISAM nicht mehr "up to Date" wegen der Einschränkung "MYISAM not supports transaction."

    In der Hilfe von MySQL hatte ich glücklicherweise gefunden, dass die Texte, welche als Text eingefügt werden C-konform sein müssen.

    ...da ich kein MySQL habe muß ich das mal nachgucken. :whistling: Logisch kann ich das aber nicht nachvollziehen. Wenn ich ein Etikett meiner Marmelade in der Datenbank speichere ("Pflaumen\Birnen") dann muß ich jedesmal darüber nachdenken wie ich das speichere? 8|

    Ich hoffe aber, dass meine Anwendung (bis zu einem bestimmten Grad) reletiv übergreifend funktioniert.
    Zumindestens sehe ich spontan kein Konstrukt, welches es nicht schon in delphi 6 oder so gab!

    8o Die Delphi Version dient dafür, daß wir dir, für die Zukunft, passene Lösungen anbieten können. Sinngemäß: Wenn du nur D7 hast brauchen wir nicht über Generics reden. :thumbup:

    PS: An dieser Stelle der Hinweis über die Lizenzfalle von MySQL.

    Devart: Bei MySQL ist man damit auch die Lizenzfalle los da man keine Libmysql.dll benötigt.
    ...
    Bei MySql ist bei closed Source Programmen immer eine Lizenz fällig - unabhängig vom Zugriff? ->
    ...
    Ist es nicht wenn du keine Teile von MySQL mitlieferst (Z.B. wenn der Kunde sich die MySQL-Serverinstallation selbst besorgt) und du keine teile von MySQL für den Betrieb zwingend nötig hast. Dies ist z.B. der Fall wenn mehrere DBMS unterstützt werden und keine Libmysql.dll mitgeliefert wird.

    ...ist MySQL vorgegeben? Oder tun es auch freie Alternativen? :)
    Tipps zur Umstellung MySQL nach MariaDB:
    delphipraxis.net/182945-mariadb-anstatt-mysql.html
    Dateien
    • wiki.png

      (29,26 kB, 8 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „haentschman“ ()

    Tagchen,

    das lässt mir ja keine Ruhe, ich muss einfach mal "gemein" sein:
    Wenn ein Anwender den ItemIndex einer ComboBox so manipulieren kann,
    dass er in die SQL nach "IntToStr" noch eine SQL-Injection hinbekommt,
    dann brauche ich mir darüber auch keine Sorgen mehr machen, denn dann
    hat der warscheinlich eh schon soviel Ahnung, dass er sich auch anderweitig
    und mit weniger Aufwand in die Datenbank hacken kann! :D
    Ehrlich gesagt nutze ich in diesem Programm nur ParamByName, da es sich meiner
    Meinung nach leichter konvertieren lässt, falls man mal auf ein anderes DBMS
    umstellen möchte. Die Anwender sind hier die Kollegen und die bekommen
    sowieso Vollzugriff auf die Datenbank ... die Daten sind einfach nicht schützenswert,
    das Programm soll das Arbeiten vereinfachen und wenn was schief geht "Pech gehabt"! ;)

    Nochmal zu dem C-Konformen Strings: Hierbei ging es nur um HeidiSQL. vielleicht lag es auch daran,
    dass HeidiSQL so arbeitete. Mit ParamByName hatte sich das aber ja glücklicherweise doch erledigt.
    Ich will gar nicht wissen, wie ich das Formatieren müsste! ;)

    Ich will mir aber auf jeden Fall nochmal die Info zu der Lizenzgeschichte zu Herzen nehmen!
    Wir wollten das zwar nur intern einsetzten, aber man muss sich ja trotzdem an Regeln halten finde ich!
    Vielen Dank für diesen Hinweis!

    MfG
    Incocnito
    Hallöle... 8o
    Ehrlich gesagt nutze ich in diesem Programm nur ParamByName,...

    Wenn du das für alle Werte konsequent handhabst, bist du auf der sicheren Seite. :thumbup:
    Es gibt andere Varianten das SQL abzulegen. Deine Variante (Add + + + + ExecSql) funktioniert, ist aber nicht wirklich testbar.

    Konntest du dir mal die Verlagerung der SQL in Ressourcen anschauen?
    :)
    Hi Zusammen.

    Das mit den Ressourcen hatte ich mir angesehen, aber ich sehe überhaubt nicht, wo der Vorteil sein soll.
    Schon gar nicht, wo eine Verlagerung der SQL-Strings in eine andere Datei das ganze lesbarer oder
    testbarer machen soll. Wenn, denke ich, versteht man sowas nur im Produktivgeschäft, wenn man zeigen
    kann wie sowas gehen soll. Ansonsten sehe ich für mich nur den Nachteil, dass ich im Quelltext nicht mehr
    sofort sehe, was in der SQL steht und damit beispielsweise ganz banal, welche Felder ich nun zur Verfügung habe.

    Vielleicht nochmal zur Lizenzgeschichte:
    Wir haben bisher mit ADS (Advantage Database Server, jetzt von SAP, vorher von Sybase, Anywhere, ...) gearbeitet und
    wollten auf MySQL wechseln. Bei ADS sehe ich den Vorteil, dass die Fehlermeldungen einfach idiotensicher sind.
    Die haben eine wirklich gute Fehlerbeschreibung. Bei MySQL hingegen ist das der blanke Horror. Ohne die Erfahrungen
    mit ADS könnte ich mit MySQL schlicht nicht arbeiten, weil ich mit den Fehlermeldungen praktisch gar nichts anfangen
    kann. "Irgendwo bei dem Wort X ist ein Fehler" ... ja besten Dank, meistens zeigt er dann noch auf eine falsche Stelle,
    vermutlich weil ich die SQLs gerne mit Zeilenumbrüchen fülle, ich weiß nicht wieso das so hochgelobt wird.
    Der Grund warum wir ADS nicht mehr einsetzen wollen, ist einfach der Support. Seit das zu SAP gewechselt hat
    ist der Support eine Katastrophe, es dauert ewig bis neue Delphi-Versionen unterstützt werden und von Windows 10
    will ich gar nicht anfangen. Ich hatte denen eine Beispiel-App (mit Delphi-Quellen natürlich) samt DB geschickt,
    mit welcher ein Fehler nachvollziehbar war und zwar vor 3 Jahren und es gibt bis heute keine Antwort geschweige denn
    Lösung dafür. Und das war ein wirklich übersichtlicher Fehler. Na gut, genug aufgeregt! ;)
    Meine Frage ist eigendlich: Hat jemand schonmal mit ADS gearbeitet, arbeitet jetzt mit einem anderen DBMS
    und kann das empfehlen? Evtl. im Zusammenspiel mit der UniDAC-Komponente von Devart, die unterstützt ja auch
    wenigstens diese beiden und soll ja ohne weitere DLLs auskommen (ok, das ist natürlich zugleich Vor- und Nachteil).
    Gab es vielleicht in diesem Forum (oder sonstwo) vielleicht eine ähnliche Frage, die ich jetzt (zugegebenermaßen
    "auf die Schnelle") nicht gefunden habe?

    Mit freundlichem Gruß
    Incocnito
    Mir fallen da auf Anhieb zwei OpenSource Datenbanken ein, die eine echte Alternative zu MySQL / MariaDB bieten:
    • Firebird, eine echte freie Datenbank mit erstaunlich kleiner Installationsgröße
    • PostgreSQL, eine echte freie Datenbank, die sehr komplex und nah an Oracle ist (oder Oracle an PostgreSQL?)
    Daneben bieten sich noch die abgespeckten, freien Version der "großen" Datenbanken an: die Express-Versionen von Microsofts SQL Server und Oracle oder gar IBM's DB2.

    Mein Favorit bei zu erwartendem hohem Datenvolumen für eigene "kleine" Projekte ist die Firebird, soll es ins Eingemachte gehen und es wird richtig aufwendig, wähle ich die PostgreSQL.

    Ein weiteres Kriterium ist die Datensicherheit, PostgreSQL bietet ein wesentlich aufwendigeres und granulareres Backup als Firebird. Letztlich musst du selbst entscheiden, welche Datenbank für dein Projekt und deine Anforderungen die Richtige ist.

    Grüße
    Mikhal
    Computer erleichtern die Arbeit -
    und die Welt ist eine Scheibe!
    Hallöle... 8o

    @Incocnito
    aber ich sehe überhaubt nicht, wo der Vorteil sein soll.

    ...das betrübt mich sehr. :/

    Schon gar nicht, wo eine Verlagerung der SQL-Strings in eine andere Datei das ganze lesbarer oder
    testbarer machen soll.

    Dein Beispiel:

    Delphi-Code

    1. qWork.SQL.Add(
    2. ' INSERT INTO' + sLineBreak
    3. + ' zugriff' + sLineBreak
    4. + ' (' + sLineBreak
    5. + ' projekt_id,' + sLineBreak
    6. + ' benutzer_id,' + sLineBreak
    7. + ' datei_name' + sLineBreak
    8. + ' ) VALUES (' + sLineBreak
    9. + IntToStr(iProjektID) + ',' + sLineBreak
    10. + IntToStr(iBenutzerID) + ',' + sLineBreak
    11. + ' :TheFileName ' + sLineBreak
    12. + ' )'
    13. );
    14. qWork.ParamByName('TheFileName').AsString := sQuellDatei;
    15. qWork.ExecSQL();

    Du mußt immer die komplette Anwendung starten um sehen ob das Statement paßt. Von Tippfehlern oder vergessene '"" gar nicht zu reden.

    Wenn du das Statement in einer Datei hast (Name: BlubbStatement.sql):

    Delphi-Code

    1. INSERT INTO zugriff (projekt_id, benutzer_id, datei_name) VALUES (:PID, :BID, :TheFileName)

    Dieses Statement kannst du direkt mit Copy/Paste, oder über das Tool direkt, in das SQL Tool deiner Wahl übernehmen und ausprobieren? ...was ist jetzt übersichtlicher? :whistling:
    Im Quelltext:

    Delphi-Code

    1. qWork.SQL.Text := TDatabase.GetSQLByName('BlubbStatement');
    2. qWork.ParamByName('TheFileName').AsString := sQuellDatei;
    3. qWork.ParamByName('PID').AsInteger := iProjektID;
    4. qWork.ParamByName('BID').AsInteger := iBenutzerID;
    5. qWork.ExecSQL;


    Im Quelltext gibt es nur einmalig global die Funktion welche dir das Statement ausliest.

    Delphi-Code

    1. function TDatabase.GetSQLByName(SQLName: string): string;
    2. var
    3. SQLStream: TResourceStream;
    4. SQLStrings: TStringList;
    5. begin
    6. Result := '';
    7. SQLStrings := TStringList.Create;
    8. try
    9. SQLStream := TResourceStream.Create(HInstance, SQLName, PWideChar(conDatabaseResourceGroupString[FDatabaseProperties.DBMS]));
    10. try
    11. try
    12. SQLStrings.LoadFromStream(SQLStream);
    13. SQLStrings.Delete(0); // Kommentarzeile
    14. Result := SQLStrings.Text;
    15. except
    16. Result := '';
    17. end;
    18. finally
    19. SQLStream.Free;
    20. end;
    21. finally
    22. SQLStrings.Free;
    23. end;
    24. end;

    Ansonsten sehe ich für mich nur den Nachteil, dass ich im Quelltext nicht mehr sofort sehe, was in der SQL steht und damit beispielsweise ganz banal, welche Felder ich nun zur Verfügung habe

    Dafür gibt es das Tool. Dort findest du alle Statements an zentraler Stelle. Das Tool sollte neben der IDE laufen... alle Statements übersichtlich sortiert und gefiltert. Das Anlegen der Statements oder die Suche nach einem Statement übernimmt das Tool.


    Zusammenfassung:

    1. Jedes Statement hat seine Datei.
    Vorteile:
    * Wiederverwendbarkeit der Statements DRY
    * Ablage der Statements im Versionskontrollsystem
    * Testbarkeit im Tool deiner Wahl
    2. Alle Statements an zentraler Stelle und nicht über den Quelltext verteilt.
    3. Die IDE kompilliert die Statements automatisch in die Ressource. Kein manuelles Todo!
    4. Übersichtlichkeit im Quelltext des "Datamodules" oder "Interface"...wie auch immer.
    5. Unterstützung mehrer DBMS ohne Quelltextänderung.

    Man muß nur mal über seinen Schatten springen und nicht immer so machen wie man es gewohnt ist. 8o
    Bilder
    • dimowa_dSRG_Black.png

      132,93 kB, 1.000×600, 9 mal angesehen

    Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von „haentschman“ ()

    Hi Zusammen,

    @Mikhal: Von PostgreSQL hört man tatsächlich auch sehr viel ... ist also nicht umsonst so verbreitet. Vielen Dank schonmal vorab für die Info.
    Vieleicht kann ich eine Umstellung auf PostgreSQL ja durchbekommen. Muss mich dann natürlich noch weiter informieren und das bei nächster
    Gelegenheit mal selbst (auf 'ner VM!?) einrichten!

    haentschman schrieb:


    ...
    ...das betrübt mich sehr. :/
    ...

    ... und mich erst! Auch hier sage ich mal: Das macht ihr ja nicht umsonst so! ;)
    Ich will es ja auch gar nicht unbedingt "immer so machen, wie man es gewohnt ist"!
    Ich habe nur ein unheimliches persönliches Problem mich selbst an solch (letztlich
    nun doch nicht gerade kleine) Änderungen heranzuwagen.
    Um das mal zu verbildlichen: Wir haben heute jemanden reinbekommen, der sich
    mit Git auskennt. Ich habe nun 4 Wochen rumexperimentiert und auch selbst
    an einer Entsprechung gearbeitet. Trotzdem habe ich innerlich eine Party
    gefeiert, als ich das rausbekommen habe. Ich traue mich auch hier nicht selbst
    da einfach so ran.
    Was, wenn irgendwas nicht so läuft, wie ich will?
    Was kann es?
    Solche Sachen verunsichern mich zu sehr, als dass ich mich an solch ein Projekt
    selbst herantrauen würde.
    Aber ich habe ihm schon gesagt, dass er sich bei mir "dahinter stellen" soll
    und mir erklären soll, wie ich das einrichte, weil ich das wirklich gerne
    wissen möchte. Ich möchte wirklich gerne wissen,
    wie alles funktioniert und nicht mich auf "hauptsache es läuft" ausruhen.
    Solch eine Einstellung finde ich Grund-verkehrt.
    Ich hoffe du merkst: Wenigstens was das anbelangt rennst du offene Türen ein! ;)

    Auch wenn es sein kann, dass ich das letztlich doch nie einsetze, weil mir die "Option
    verschlossen bleibt" (ich weiß nicht wie ich das anders nennen kann), vielleicht
    trotzdem noch die Frage: Wenn ich jetzt von den Daten her erst Schritt 1 durchführen muss
    und dann irgendwann Schritt 2, und im Schritt 2 wieder eine SQL ist. Wie geht man am Besten
    beim Testen vor? Bereitet man für jeden Datensatz vor? Das wäre halt auch ein Grund, warum
    ich das gleich in der Software selbst tracen würde, ich "muss" ja eh die Daten vorbereiten,
    bevor ich die zu-testende-SQL aufrufen kann. Evtl. muss man sogar ganze Datenströme in der
    Datenbank speichern (wer hat noch nie ein Bild in der Datenbank gespeichert?), wobei ich
    dann natürlich das BLOB-Feld nicht auslassen möchte, nur weil es nicht geht.
    Ihr merkt warscheinlich schon, mich enttäuscht das total, dass ich seit dem Studium gefühlt garnichts
    dazugelernt habe und immer mehr vom Studium vergesse. ;(
    Anders herum kann ich gar nicht verstehen, wie man ohne die ungarische Notation auch nur
    eine Sekunde arbeiten kann! :P Jetzt spiele ich mal einen 100-jährigen: "Nicht alles war damals schlechter!" :D

    Auf jeden Fall wünsche ich allen Lesern noch ein wunderschönes Wochenende (oder falls ihr das später liest
    einen angenehmen und erfolgreichen Tag)!

    MfG
    Incocnito
    ...noch ein wunderschönes Wochenende...

    ...dir auch. 8o


    Anders herum kann ich gar nicht verstehen, wie man ohne die ungarische Notation auch nur
    eine Sekunde arbeiten kann! Jetzt spiele ich mal einen 100-jährigen: "Nicht alles war damals schlechter!"

    ...jeder wie er mag. Alles ist gut. :)
    und immer mehr vom Studium vergesse

    ...willkommen im Club. ;(
    ...vielleicht trotzdem noch die Frage: Wenn ich jetzt von den Daten her erst Schritt 1 durchführen muss
    und dann irgendwann Schritt 2, und im Schritt 2 wieder eine SQL ist. Wie geht man am Besten
    beim Testen vor? Bereitet man für jeden Datensatz vor?

    Die Frage verstehe nicht wirklich. :whistling: Kannst du ein Beispiel machen? :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „haentschman“ ()