Tabelle Update, Statement muss mit "SELECT" beginnen

N

Nappo

Benutzer
Beiträge
11
Hallo,

kurz und schmerzlos:
Ich möchte einen Datensatz in einer Tabelle per SQL updaten
Code: 
SELECT Aid, storable
FROM fet_user.fet_Article
WHERE AID = '11E1660'

Das ganze passiert innerhalb eines WaWi Systems. Hier sind zwar Datenabfragen erlaubt, allerdings nur wenn sie mit der Anweisung "SELECT" beginnen, technisch gibt (soll es geben) keine Einschränkungen, es wird lediglich der erste Ausdruck im Statement überprüft. Wie kann ich einen DS mit einem Skript updaten der miot "SELECT" beginnt? Ich habe schon viel gesucht und gefummelt, komme aber nicht klar. Mein letzter Versuch nach langem probieren:



Code: 
SELECT Aid
FROM fet_user.fet_Article
WHERE AID = '11E1660'

UNION ALL

SELECT Aid
FROM (
  UPDATE fet_user.fet_Article
  SET STORABLE = 1
output inserted.AID
  WHERE AID = '11E1660'
) AS dummy_table

Wäre für Hinweise oder Lösungen echt dankbar.

Gruß
Sugar
 
Werbung:
Ich habe das Topic bereits im anderen Forum gelesen und wäre gespannt wenn hier jemand noch einen Workaround findet.
Wobei man sich fragen darf: Warum verhindert das WaWi wohl das man so irgendwelche schwindligen Änderungen an den Daten macht.
Manche Server-Client Systeme kriegen Änderungen und Events nur mit wenn sie die Daten aktiv verarbeiten. Wenn du also Daten manipulierst wüsste das System gar nicht welche Aktionen gesetzt werden müssten. Daher ist das vermutlich der Grund warum das System derart zugemauert ist.
Von daher - Finger weg.
 
geht nicht??

@MDDaniel: Beim Hersteller der WaWi weiß man schlicht nicht warum das Feld per Skripting schreibgeschützt ist.

Es handelt sich im ein ganz simples Kennzeichen das keinerlei Abhängigkeiten in der Datenbank hat - praktisch wie ein Vorname in einer Adresstabelle. Über die Oberfläche kann man es problemlos ändern und auch über das Managment-Studio gibt es keine Probleme.
 
Also mal kurz:
- Die WaWi hat einen Schutz eingebaut der verhindern will das du anderen Code ausführst als einen Select. (Zugegeben, die Filterung auf das erste Schlüsselwort zu begrenzen ist mindestens fragwürdig.)
- Der Herstelller der WaWi weiß nicht, wieso das so ist. Okay.... das macht mich skeptisch. Sind die so dumm? Ist die Software so alt und scheiße? Lügt hier einer?
- Du willst das jetzt "hacken". Kann man versuchen, geht vielleicht. Ich weiß nicht ob ich da legal bei helfen dürfte aber SQL Strings escapen könnte man probieren. Ich kann mir nicht vorstellen das wirklich nur das erste Wort geprüft wird.
- Du hast Zugriff auf die Datenbank in SSMS. Warum machst du das nicht mit einem vernünftigen SQL Statement mit vernünftigen Datenbankrechten?
 
Nappo schrieb:
geht nicht??
Zum Vergrößern anklicken....
wer weiß, was der Hersteller da gemacht hat. Du könntest mit einem Kommentar anfangen, mit BEGIN eine Transaktion eröffnen oder SELECT 1; in den Raum brüllen, gefolgt von Deinem UPDATE. Aber es kann auch gut sein, daß das z.B. via Rechtekonzept schon nicht geht - und der Hersteller gute Gründe dafür hat, sich die DB nicht durch simple Anfängerfehler (UPDATE ohne WHERE, you name it ...) kapott machen zu lassen. Apropos zu lassen: laß es sein, frag den Hersteller. Ihr zahlt ja sicher Support, oder? Na also...
 
@ukulele:
Nach Auskunft des herstellers wird tatsächlich das erste Wort im Skript geprüft. Wenn das ein "SELECT" ist greifen aber auch weitere Syntaxprüfungen.

"Sind die so dumm?" - da gehen die Meinungen auseinander... Fakt ist, dass mir keiner beantworten kann warum das so ist und das die Änderung daran eigentlich unkritisch ist.

"Hacken" - ja, wenn man das so nennen will. Ich bin da Praktiker, das Kennzeichen was ich ändern möchte soll als Ergebnis einen vorgelagerten Prozesses und dessen Ergebnis angepasst werden. Aktuell muss das manuell getan werden. "Eigentlich" - so die Aussage, sollte das über die eigene Skriptsprache auch möglich sein. Nun aber behindert das eben eine gewisse logische Automatisierung.

"- Du hast Zugriff auf die Datenbank in SSMS. Warum machst du das nicht mit einem vernünftigen SQL Statement mit vernünftigen Datenbankrechten?"
Wie? Wie soll ich im SSMS auf eine Aktion im WaWi reagieren?
 
akretschmer schrieb:
wer weiß, was der Hersteller da gemacht hat. Du könntest mit einem Kommentar anfangen, mit BEGIN eine Transaktion eröffnen oder SELECT 1; in den Raum brüllen, gefolgt von Deinem UPDATE. Aber es kann auch gut sein, daß das z.B. via Rechtekonzept schon nicht geht - und der Hersteller gute Gründe dafür hat, sich die DB nicht durch simple Anfängerfehler (UPDATE ohne WHERE, you name it ...) kapott machen zu lassen. Apropos zu lassen: laß es sein, frag den Hersteller. Ihr zahlt ja sicher Support, oder? Na also...
Zum Vergrößern anklicken....
Darauf wird es wohl hinauslaufen.. Für die Antwort will der Hersteller einen Rechercheaufwand - losgelöst vom Support
 
Nappo schrieb:
Wie soll ich im SSMS auf eine Aktion im WaWi reagieren?
Zum Vergrößern anklicken....
Wenn es eine echte Aktion in der DB gibt kann sie per Trigger wunderbar darauf reagieren. Aber auch wenn das nicht so ist wird der Select ind er WaWi ja vermutlich auch von irgendeinem Benutzer initiiert, dann kann der auch eine DB Aktion anstoßen. Sicherlich eine Frage von Komfort aber ich würde alles versuchen um das Konstrukt "Update durch kaputtes Select-Statement" zu vermeiden. Und dann ist das ja noch so eine Sache, meist kennt man einige Möglichkeiten gar nicht. Du hast uns nicht verraten was wann gemacht werden soll.

Mit Vollzugriff auf die DB könnte man z.B. Trigger anlegen die deine Daten direkt anpassen, wenn sie entstehen. Aber dazu müsste man den Prozess kennen.
 
Dürfen Funktionen in SQL Server UPDATEs machen?

Wenn ja, schreibe ein Funktion die das UPDATE macht und rufe sie mit select meine_funktion(...) auf

Aber bei vielen kommerziellen Produkten geht damit das Recht auf Support flöten, wenn man "ausserhalb" der Anwendung selber in der Datenbank Änderungen macht. Also lieber vorher klären, was mit eurem Supportvertrag passiert wenn Du das machst.
 
Nappo schrieb:
geht nicht??

@MDDaniel: Beim Hersteller der WaWi weiß man schlicht nicht warum das Feld per Skripting schreibgeschützt ist.

Es handelt sich im ein ganz simples Kennzeichen das keinerlei Abhängigkeiten in der Datenbank hat - praktisch wie ein Vorname in einer Adresstabelle. Über die Oberfläche kann man es problemlos ändern und auch über das Managment-Studio gibt es keine Probleme.
Zum Vergrößern anklicken....

Würde man ein Update zulassen hat man nicht im Griff was ein Benutzer ändert. Jedenfalls nicht auf eine einfache Art. Und wenn es über die Oberfläche gemacht wird kann ein Client oder Serversystem alle notwendigen Abhängigkeiten berücksichtigen, wie zum Beispiel Lagerfähig = Berücksichtigen auf irgendwelchen Inventurlisten ... das hat vielleicht keine direkten strukturellen Abhängigkeiten aber logische.
Von daher ist die organisatorische Vorgehensweise mit einer Sperre nachvollziehbar.

SSMS wird nur jammern wenn du irgendwelche Constrains verletzt.
Und wenn du mit Triggern rumbastelst dir hinterrücks Daten ändern und dabei vielleicht die Geschäftslogik beeinträchtigen wird irgendwann sich jemand sehr wundern. Vielleicht schon beim nächsten Update.

Konzeptionelle Frage:
Nappo schrieb:
Wie soll ich im SSMS auf eine Aktion im WaWi reagieren?
Zum Vergrößern anklicken....
Warum musst du das überhaupt?
Ist die Eingabe nicht korrekt? Dann hast du ein organisatorisches Problem nicht ein technisches.
 
Richtig, alle Änderungen an der DB haben die großen Nachteile das Support i.d.R. verloren geht und beim update schnell Probleme auftreten. Meist kann man aber selbst auf Datenbankänderungen reagierten oder den Trigger vorrübergehend entfernen.

Was ein Update über einen Select angeht trifft das mit dem Support aber sicher in gleicher Weise zu. Auch verändert das Update ja die Daten genau wie ein Trigger das machen würde, in beiden Fällen muss ich sicherstellen das das korrekt und vollständig erfolgt. ich bezweifle z.B. auch das die WaWi echte Constraints hat die Datenkonsistenz sicherstellen, das liegt häufig nur im Anwendungsserver, also Daten kann man sich in beiden Fällen in gleicher Weise kaputt knüppeln und auch das Update kann nach einem Update der Datenbank nicht mehr korrekt funktionieren.

Daher wäre mir ein Trigger immer noch lieber als ein "heimliches" Update, beides muss mit Sorgfalt erfolgen und gut dokumentiert sein.

Interessant wäre auch noch mit welchen Rechten der Select läuft, aber vermutlich hat sich der Hersteller da wenig Mühe gegeben und asich ganz auf seine Syntaxprüfung verlassen.
 
Probier doch mal ganz auf blöd sowas. Mit etwas Glück merkt deine WaWi nicht, dass das Select ein Kommentar ist.
Code: 
-- SELECT
update <table>
set <column> = <value>
where ...
MDDaniel schrieb:
SSMS wird nur jammern wenn du irgendwelche Constrains verletzt.
Zum Vergrößern anklicken....
Ist nicht auf SSMS beschränkt und hat auch nix mit SSMS zu tun.
 
Werbung:

Ähnliche Themen

R
Update einer Spalte mit Wert aus anderer Tabelle
Antworten
3
Aufrufe
4K
Charly
Charly
Zurück
Oben