Betreff: Erweiterte SQL-OptionenIch bin mir nicht sicher, ob dieser Kommentar einen separaten Wunschartikel erfordert, aber angesichts der Allgemeingültigkeit des ursprünglichen Wunschartikels scheint er verwandt genug zu sein, um ihn in diesen aufzunehmen:
Ich würde mir wünschen, dass JMP einen aktiven SQL-Editor enthält, wenn es mit einer externen Datenbank verknüpft ist (Dropdown-Auswahl beim Eingeben von SQL, automatisches Ausfüllen syntaxkonsistenter Befehle usw.).
Derzeit kann man fehlerhaftes SQL in das Feld eingeben und die einzige Rückmeldung ist ein allgemeiner Fehler.
Ich denke, der ursprüngliche Beitrag zum Wunschlisteneintrag geht noch einen Schritt weiter und möchte, dass sich die Abfrage-Builder-GUI (oder der Assistent, wie ich ihn nenne) an die eingegebene SQL anpasst.
Betreff: Erweiterte SQL-OptionenHallo @Schwung . Danke für die Unterstützung 
Ein aktiver SQL-Texteditor mit d Dropdown-Auswahl während der SQL-Eingabe, automatisches Ausfüllen syntaxkonsistenter Befehle usw
Tolle Idee! Ich will es!
Dies ermöglicht es mir, die ursprüngliche Idee weiter zu präzisieren – zu differenzieren – und auch zu verknüpfen.
Der ursprüngliche Wunsch entstand durch die Feststellung, dass es einige „unbekannte“ SQL-Strings gibt – Code, der nicht über die GUI erstellt werden kann.
Die Idee also: entweder diese Funktionalität hinzufügen oder eine Möglichkeit bereitstellen, solche unbekannten SQL-Strings zum automatisch generierten Code hinzuzufügen *) – ohne die Möglichkeit zu verlieren, die GUI weiter zu verwenden.
*) Dazu muss die GUI (Assistent) muss nicht verstehen die zusätzlichen Strings.
@Schwung Der aktive SQL-Editor könnte eine Möglichkeit sein, diese Idee umzusetzen. Wenn der Editor die Syntax versteht, kann er Dropboxen und Fehlerhervorhebung unterstützen.
Also cool für Benutzer, die sich an Standard-SQL halten.
Und zu *):
Wenn es Ausdrücke gibt, die der aktive SQL-Editor nicht versteht, markiert er solche Ausdrücke als Fehler – bietet aber dennoch die komfortable Unterstützung für die verbleibenden Zeichenfolgen – und für die Gesamthierarchie.
Der aktive SQL-Editor erinnert mich stark an den Jmp-Formeleditor.
Ich denke also, dass dies die ultimative Lösung wäre:
ein SQL-Abfrageeditor, genau wie der Jmp-Formeleditor – mit Inline-Syntaxunterstützung + Hierarchieprüfungen.
... und wenn der Benutzer Code verwenden möchte, der dem Editor unbekannt ist, könnte man dafür eine bestimmte Funktionalität bereitstellen
- manche „Unbekannter Code im Inneren“ – Kästchen die an jeder beliebigen Position in der bekannten Hierarchie platziert werden können.
erweiterte SQL-Optionen☐ coole neue Funktion
☑ könnte vielen Benutzern helfen!
☐ beseitigt einen „Bug“
☐ schön zu haben
☐ Niemand braucht es
Was hat diese Wunschlistenanfrage inspiriert?
Der Query Builder in Jmp eignet sich gut zum Generieren von SQL-Abfragen über eine GUI.
Es gibt jedoch Abfragen, die nicht über die GUI generiert werden können:
Datenbankzugriff
Wie kann mit JMP 17 im Abfrage-Builder „WITH UR“ am Ende des SQL-Codes hinzugefügt werden?
Die einzige Lösung im Moment: Wechseln Sie zu benutzerdefiniertem SQL – und verlieren Sie in diesem Moment alle GUI-Optionen, um weitere Änderungen an der Abfrage vorzunehmen.
Welche Verbesserung würden Sie sich wünschen?
Bitte verbessern Sie die GUI, um eine erweiterte SQL-Option bereitzustellen:
- Fügen Sie die Funktionalität zum „Explodieren“ von Einträgen und „Indizieren“ von Spalteneinträgen hinzu
- Ermöglichen Sie dem Benutzer die manuelle Eingabe erweiterter SQL-Zeichenfolgen, die dann an bestimmten Positionen der Haupt-SQL-Abfragezeichenfolge hinzugefügt werden können.
Warum ist diese Idee wichtig?
Benutzer sind nicht mehr gezwungen, den Query Builder zu verlassen, wenn sie ihrer Abfrage einen Ausdruck hinzufügen müssen, der von der Query Builder-GUI nicht unterstützt wird.
Weitere Wünsche eingereicht von
DatenzugriffBetreff: Erweiterte SQL-Optionen – Status geändert in: BestätigtBetreff: Erweiterte SQL-OptionenIch möchte einen spezifischeren Verbesserungswunsch hinzufügen, der möglicherweise auch relativ einfach umzusetzen ist: Mehr Flexibilität bei berechneten Spalten.
Derzeit erlaubt der Formeleditor nur die Eingabe einer begrenzten Anzahl von Funktionen und Operatoren; Nicht erkannte Syntax (einschließlich einfacher Dinge wie CAST oder CONVERT) wird abgelehnt. Wäre es möglich, entweder Unterstützung für den gesamten Funktionsumfang beliebter DB-Engines wie SQL Server hinzuzufügen oder einfach die Eingabe von beliebigem SQL-Code als Formel für eine berechnete Spalte zu ermöglichen? Vielleicht durch Hinzufügen der Option „Benutzerdefinierte Ausdrücke zulassen“ zum Dropdown-Menü für SQL-Dialekte?
