![]() |
Datenbank: MySQL • Version: 8 • Zugriff über: egal
MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
ich will per SQL ein Feld mit Prefix zurück geben:
Code:
MS SQL macht hier wie erwartet ein String-Zusammensetzung.
select '957' + matnr, matnr from mat
MySQL (8) interpretiert das erste '957# als Zahl und das Feld matnr ebenfalls als Zahl und Addiert die beiden. matnr ist aber er ein varchar-Feld W T H haben sich hier die Entwickler gedacht? Zugriff/versuch mit MySQL Workbench und HeidiSQL Wie bekommt man diesen Excel/Access-Blödsinn bei MySQL wieder weg? |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Bei Oracle, PostGres, Firebrid, Interbase macht man's per ||
Bei MySQL: ![]() |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Bei MySQL scheint das ein boolean-or zu sein
|
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
SQL-Code:
geht, soweit ich das mitbekommen habe, nur bei Microsoft.
select 'Zeichenfolge' + 'Zeichenfolge' from tabelle
Andere rechnen bei der Verwendung von +, sofern sich die Werte links und rechts vom + in Zahlen konvertieren lassen. Andernfalls gibt's 'nen Fehler. Standard dürfte Concat sein, wobei man hier (strenggenommen) nummerische Werte per Cast oder Convert erstmal in Zeichenfolgen umwandeln müsste. Die Verwendung des + ist praktisch, aber man kann nicht mit zwingender Sicherheit vorraussagen, was man als Ergebnis bekommen wird. Zeichenfolge + Zeichenfolge = Zeichenfolge Zahl + Zeichenfolge = Zeichenfolge Zeichenfolge + Zahl = Zeichenfolge Aber wehe, die Zeichenfolgen lassen sich von der Datenbank implizit in Zahlen verwandeln, dann kann auch gelten: Zeichenfolge + Zeichenfolge = Zahl Zahl + Zeichenfolge = Zahl Zeichenfolge + Zahl = Zahl Und wenn man dann etwas schreibt, was mit beliebigen Datenbanken funktionieren soll: Fröhliches Fehlersuchen. |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Zitat:
Feste Zeichenfolge + varchar-Feld |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
concat funktioniert.
Das genügt mir erstmal für meine One-Time Datenänderung |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Zitat:
Und wenn eine feste Zeichenfolge in eine Zahl umgewandelt werden kann und der Inhalt des VarChar-Feldes ebenfalls, kann durchaus auch Zahl als Ergebnis rauskommen. Kommt halt auf die Datenbank an. |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Vielleicht kannst Du mit irgendwelchen "Strict Mode"s mySQL etwas in Deine Richtung dressieren. (Wobei das + von MS jetzt m.E. auch nicht DER Standard ist)
Die Strict Modes sorgen jedenfalls häufiger für solide Fehlermeldungen und Verhalten, wie man es im Standard / bei den anderen gewohnt ist. Das kann vor allem hilfreich sein, wenn man im Testumfeld agiert. Ich finde einen harten Fehler grundsätzlich sympathischer als solchen impliziten Konvertierungsmist, der sich überall durchzieht und dann erst beim Jahresabschluss auffällt. Da ich nie freiwillig mit mySQL arbeiten würde, kann ich keine konkreteren Hinweise liefern. |
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Zitat:
Leider kenn ich das nicht ob es sowas gibt. Zitat:
Wer ärgert sich nicht wenn im Öffnen in Excel teschnische IDs als Zahlen oder Datum interpretiert werden und man dann erstmal wieder schauen muss wie man das weg bekommt. Zitat:
|
AW: MySQL und Excel-Automatismen beim Interpretieren von SQL-Statements?
Zitat:
![]() Ich finde mySQL geht gar nicht, ewig keine Updates, ein Meer von altem Schrottcode im Internet*, der einfach nicht aussterben will. Gruselig. Oracle DB ist da eher einfach nur eine Preisfrage. (Und Vertrauen darauf, dass es keine unerwartetenden Strategiewechsel gibt) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz