Zugriff auf SQL Datenbanken über Web

[greyhound]

Hallo an alle SQL Gurus,
seit kurzem muß ich mich mit ein paar strategischen Fragen zur Abfrage von SQl Datenbanken befassen.
Da ich aber nur sehr wenig SQL Kenntnisse und keine Programmierkenntnisse habe, wollte ich einmal ein paar Ratschläge zum sinnvollen Aufbau eines Datenbank Frontends für SQL Server 2005 von den Experten haben.

Voraussetzungen:

Es gibt verschiedene PC, auf denen u.a. ein Delphi Programm zur Prozeßsteuerung läuft (mit diversen Paradox Tabellen) und der Internet Explorer ist verfügbar.
Auf diesen PC ist teilweise Windows NT 4.0, teilweise Windows 2000 und meistens Windows XP installiert.

Ziel:

Ich möchte ohne zusätzliche Softwareinstallation von diesen PC aus auf bestimmte Parameter- und Konfigurationstabellen auf dem SQL Server zugreifen und ich möchte aus einer Produktionsplanungsdatenbank für entsprechende Anlagen vorgesehene Daten abfragen, an die Prozeßsteuerung, übergeben und nach Prozeßende die Daten mit Statusbit zurück an die Datenbank schicken und eine lokale Sicherheitskopie auf dem jeweiligen Anlagen PC belassen.

Ich sehe dafür momentan 3 Lösungsansätze, wobei für die Produktionsplanungsdatenbank eigentlich nur Punkt 2 in Frage kommt:

1. Da ich mich relativ gut mit MS Access auskenne, könnte ich mir vorstellen, ein Accessprojekt zu erstellen und in diesem die Formulare für den Datenbankzugrif zu erstellen.
Kann man die unter MS Access möglichen Parameterabfragen auch bei SQL Sichten anwenden, z. B. beim Zugriff über MS Query zum Eingrenzen eines Datumsbereiches oder einer Identnummer?

2. Die 2. Möglichkeit wäre die Erstellung des Frontends unter Delphi (in diesem Fall 5.0) und dann der Austausch der Daten von den Paradox Tabellen lokal mit den SQL Tabellen.

3. Ideal wäre meiner Meinung nach aber die Erstellung einer Webseite auf einem Webserver, auf die dann mit dem Internet Explorer zugegriffen werden kann.

Dazu hätte ich folgende Fragen:

zu 1.
Sollte man den für Access verfügbaren Dokument Viewer verwenden oder sollte man ein Run Time Modul erstellen und dann die Zugrifsdatei.exe auf den PC starten?
Gibt es evtl. unter Windows NT Probleme mit SQL Server 2005?



zu 3.
Welche Möglichkeiten des Zugriffs auf den SQL Server gibt es prinzipiell?
Kann der Webserver in den SQL Server integriert werden oder muß es einen extra Webserver geben?

Allgemein:
Welche Variante würdet Ihr für am sinnvollsten halten bzw. welche Variante würde den geringsten Programmieraufwand bedeuten?

Wie seht Ihr den Datenaustausch über XML als offene Schnittstelle mit verschiedenen Prozeßsteuerungsprogrammen ?


Oder hättet Ihr noch eine andere Idee?

Gruss Tilo und vielen Dank im Voraus für die Bemühungen

[Bernhard Geyer]

Access würde ich vergessen. Wird vermutlich über kurz oder lang von MS ähnlich wie Foxpro eingestellt

Einen direkten Zugriff (z.B. mit Delphi über ADO) würde ich nur nehmen wenn es ein nicht öffentliches Netz ist. SQLBlast und Co. haben schon oft genug gezeigt das öffentlich zugreifbare SQL-Server (hier oft der MS SQL Server) zur Viren/Wurmschleuder mißbraucht wurden.

Falls eh der MS SQL Server als Backend fest steht, würde ich überlegen auch die lokale Version z.B. mit der kostenlosen MS SQLExpress-Version auszustatten so das zu Datenbanksynchronisation Bordmittel der Datenbank (Stichwort Replikation) verwendet werden können.

[databoss]

Hallo Tilo,

spannendes Projekt!

Ich würde das auf jeden Fall mit Delphi und ADO machen. Ob ADO unter NT4 Probleme macht kann ich nicht sagen, aber dann gäbe es immer noch BDE+ODBC. Mit Delphi auf jeden Fall kein Problem. Zumal Du damit ausführbare Prg. erzeugen kannst, die nicht installiert werden müssen, sondern "einfach so" lauffähig sind.

Zu Deiner Frage zu 3.
per ODBC, ADO und über sog. native SQL Treiber.

Aus meiner Sicht ist die Speicherung der Daten lokal mit Access (per Delphi) völlig okay. Ich halte es für nicht wahrscheinlich, dass Access in Kürze eingestellt wird. Und selbst wenn, ist das Datenformat ja nicht ungültig und kann weiterbenutzt werden, siehe Paradox.

Richtig ist auch dass es quasi lokale MS SQL Express Version gibt, ob die jedoch noch untzer NT4 laufen bezweilfe ich.

Gruß Florian

[Bernhard Geyer]

Und selbst wenn, ist das Datenformat ja nicht ungültig und kann weiterbenutzt werden, siehe Paradox.

Bedenkte das die JET-Engine nicht mehr bestandteil von MDAC ist. D.h. es gibt schon genügend (Embedded-XP)-Rechner die kein JET-Engine haben und man auch keine Chance hat dies ohne eine Access-Vollversion nach zu installiern.

Richtig ist auch dass es quasi lokale MS SQL Express Version gibt, ob die jedoch noch untzer NT4 laufen bezweilfe ich.

Ist NT4 wirklich noch relevant?

[hwoess]

Hallo Bernhard,

... und man auch keine Chance hat dies ohne eine Access-Vollversion nach zu installiern.

Ganz so schlimm ist es gottseidank nicht. Jet ist zwar nicht mehr in der MDAC dabei, kann aber in einem zweiten Schritt nachinstalliert werden und das von Windows95 bis inklusive WindowsServer2003:
http://support.microsoft.com/kb/271908/DE/
http://support.microsoft.com/kb/239114/DE/

bye,
Helmut

PS: zur Frage von Greyhound: ich habe solche Aufgaben sowohl mit Delphi als auch Webservice und Java gelöst, hatte aber mit Webservice/Java wesentlich mehr Probleme als mit Delphi/ADO. Würde daher selber sicher zu Delphi greifen. Vielleicht auch deswegen, weil Delphi mein täglich Brot ist und Websachen mit Java und XML die rühmlichen Ausnahmen
Sicherheitsbedenken hätte ich da auch nicht, da es besonders ab SQL-Server 2008 ganz einfach ist, mit Zertifikaten und verschlüsselter Verbindung zu arbeiten. Wenn man dann noch den Standardport wechselt, einen eigenen Instanznamen verwendet, den Browserdienst nicht aktiviert und eventuell die Firewall nur für gültige IP's freischaltet, dann ist eine Attacke bzw. ein Einbruch schon sehr, sehr unwahrscheinlich.

[Bernhard Geyer]

Ganz so schlimm ist es gottseidank nicht. Jet ist zwar nicht mehr in der MDAC dabei, kann aber in einem zweiten Schritt nachinstalliert werden und das von Windows95 bis inklusive WindowsServer2003:

Hast du es schon mal bei einem XP Embedded probiert wo keine JET-Engine installiert war Bei der "normalen" Installation ist auch bei Vista die JET-Engine installiert und diese wird durch die "normalen" SP-Updates natürlich aktualisiere.

[hwoess]

Okay, XP Embedded habe ich etwas "übersehen" und kann daher diesbezüglich nichts sagen. Aber davon abgesehen wird uns Access im Großen und Ganzen sicher noch einige Zeit erhalten bleiben (auch wenn ich es selber schon seit gut 10 Jahren nicht mehr verwende).

bye,
Helmut

[greyhound]

Zugriff auf SQL Datenbanken über Web

Hallo erst mal und vielen Dank für Euer Interesse,
Windows NT ist leider noch relevant, da ich das Prozeßsteuerprogramm ( Delphi 5.0) zwar zum Laufen gebracht habe, aber es ca. aller 2 Sunden einen Profibusalarm von der mit dem PC gekoppelten SPS (Moeller PS416) gibt.
Das ist leider ein ungelöstes prinzipielles Problem, was auch unter NT auftritt, aber ca 10 mal so oft unter XP)
Aus den Antworten entnehme ich, das der Datenbankzugriff auf den SQL Server über Delphi erfolgen sollte. Dann könnte ich aber gleich die schon vorhandenen Paradox Tabellen und die BDE verwenden, oder ?

Ich habe in der Grobplanung vorgesehen, für jeweilige Technologieabschnitte jeweils eine eigene getrennt administrierbare Datenbank einzurichten und mit den dort gespeicherten Views auf eine zentrale Datenbank zuzugreifen. Die View Datenbank würde ich dann als ODBC Datenquelle einrichten und vom lokalen Delphi Programm auf diese Views zugreifen.
Könnte man vom Delphi aus auch direkt auf dem SQL Server gespeicherte Prozeduren und Views aufrufen, ähnlich wie Parameterabfragen bzw. Aktualisierungsabfragen unter Access und nur die Kriterien bzw. Filter übergeben?
Oder sollte man direkt die SQL Scripte unter Delphi ausführen?

Gruss Tilo

[hwoess]

Die BDE und die Paradox-Tabellen würde ich nur übernehmen, wenn ich dazu absolut gezwungen werde - freiwillig niemals! Meiner Erfahrung nach wäre eine stabile und problemlose Lösung das vorhandene Delphi 5 (ich gehe davon aus, dass es mindestens die Professional-Version ist) mit den ADO-Komponenten. Wenn ADO nicht bereits dabei ist, würde ich die Komponenten von http://www.winsoft.sk/Adonis.htm oder http://www.devart.com/sdac/ empfehlen.
Dazu dann den SQL-Server am Server sowieso und auf den Clients die Paradox-Tabellen, je nach Anforderung, durch SQL-Express oder SQL-Compact ersetzen.

bye,
Helmut

[Bernhard Geyer]

Paradox und BDE ist heutzutage ein garant für zerschossene DB's. Kann man gerade noch bei Programmen akzeptieren die keine weiterentwicklung mehr bekommen. Für alles andere ist BDE ein Garant für Probleme.

[greyhound]

Und XML

Hallo,
da Ihr alle von BDE abratet, wie wäre es dann mit Export in Textdatei (z. B. *.xml) oder mit direkt auszuführendem SQL Script unter Delphi?
Es geht nur darum, das ein Datensatz vom SQL Server in ein bestehendes Delphi Programm übernommen werden soll und nach Prozessende dieser Datensatz zurück zum SQL Server geschickt werden soll.
Gruss Tilo

[hwoess]

Möglichkeiten gibt es viele. Mir ist nur nicht klar, was du jetzt wirklich genau machen musst, was davon aufgrund anderer Elemente nicht verändert werden darf (zB die Paradox-DB) und was du dir aussuchen kannst (zB Delphi).
Eine Möglichkeit wäre zB mit dem SQL-Server und dem Agent zu arbeiten und damit Text- oder XML-Files zu lesen und/oder zu schreiben. Diese kann man dann auch in Delphi lesen und/oder schreiben und damit bräuchte man nicht mal ein datenbankfähiges Delphi, da würde sogar eine Personal-Edition reichen. Ob sowas sinnvoll ist, ist wieder ein anderes Thema.

bye,
Helmut

[greyhound]

Hallo,
hier noch mal kurz der jetzige Stand und das Ziel der Anpassung:
Derzeit wird ein mit Delphi 5.0 erstelltes Steuerprogramm genutzt, um einen Prozeß zu steuern.
Hierbei werden von einem Steuerprogramm in lokalen Paradoxtabellen gespeicherte Daten mit einer SPS Simatic S7 ausgetauscht. Dazu wird derzeit die BDE verwendet. Das Steuerprogramm ist so geschrieben, das auch ohne Zugriff auf das Netzwerk und die zentrale Datenbank Rezepte geladen werden können.
Beim Prozeßstart wird jetzt von einem Ausdruck von einer zentralen Datenbankabfrage eine ID Nummer manuell in die lokale Datenbank eingetragen und von dort in Datenbausteine der SPS geschrieben.
Zukünftig soll über eine Sicht auf diese zentrale Datenbank zugegriffen werden, um alle für diese Anlage vorgesehenen Datensätze in eine lokale Datenbank zu übertragen. Falls kein Zugriff auf die Zentraldatenbank möglich ist, sollen diese Daten manuell in die lokale Datenbank eingetragen werden können und nachträglich mit der Zentraldatenbank abgeglichen werden. Nach Prozeßende soll dann ein Statuswert Prozeß bzw. Anlagen ID und eine Fahrtnummer in die zentrale Datenbank eingetragen werden.
Danach wird vom nächsten Technologieschritt auf dieZentraldatenbank zugegriffen
Es soll also vom Einbringen der Grundstoffe bis zum Einlagern in ein Lager der komplette Produktionsverlauf nachvollzogen werden können.
Die Schnittstelle von der Zentraldatenbank zu lokalen Datenbanken in verschiedenen Technologieschritten soll standardisiert und flexibel mit verschiedenen Steuerprogrammen herstellerunabhängig bei verschiedenen Technologieschritten verwendbar sein.
Meine Idee ist, verschiedene Datenbanken für einen jeweiligen Technologieschritt anzulegen und dort die jeweiligen Views auf die eigentliche Zentraldatenbank abzulegen.
Diese einzelnen Datenbanken werden dann als ODBC Datenquelle für die jeweiligen Anlagen angelegt. Der Datenaustausch erfolgt dann über XML, Datenkopplung über SQL Scripte o. ä..
Hier setzt nun meine Frage an, welche Variante(n) die beste(n) ist bzw. sind.

[hwoess]

Wenn man die alte Applikation komplett durch die neue ersetzen und so auch Paradox eleminieren kann, würde ich Delphi 5 hernehmen und um die ADO-Komponenten erweitern, am Server sowieso den SQL-Server(ev. Express) und auf dem Client SQL-Express als DB einsetzen. Einfach, günstig, schnell, stabil und wartungsarm (wenn der Programmierer sein Handwerk versteht).
Wenn am Client nur ein einziges Delphi-Programm für die Kommunikation sowohl zum Server als auch mit der SPS7 läuft und die Datenmenge je Client nicht zu umfangreich ist, könnte man da auch direkt mit einer typisierten Datei arbeiten. Delphi unterstützt das sehr gut.

bye,
Helmut

[Edit]: in diesem Fall würde ich mir auch Delphi TurboExplorer ansehen, das ist eine abgespeckte Version von Delphi2006 die nichts kostet, mit der man aber auch kommerzielle Sachen machen darf. Die sollte in diesem Fall sogar reichen und dbExpress/dbGo ist auch schon dabei, da müsste man dann kein ADO kaufen ( http://www.delphi-treff.de/backstage.../turbo-delphi/ ).
VisualStudio ginge natürlich genauso. Oder JAVA.... Aber ich bin ja Delphi.Fan.

[greyhound]

Hallo, genau das ist das Problem es gibt keinen Programmierer mehr in der Firma. Alle Änderungen müssen von einer Fremdfirma programmiert und somit auch entsprechend bezahlt werden. Außerdem läuft die jetzige Applikation auch stabil und muß nur um die genannten Tabellen erweitert werden.
Ich habe den Programmierer auch mal spaßenshalber gefragt, ob man die Software updaten könnte. Er sagt, das es sicherlich keine Probleme geben würde, aber da traue ich mich nicht heran, solange es keine triftigen Gründe gibt, würde ein Update auch nur Geld kosten und keine nennenswerten Verbesserungen bringen.
Die Datenmengen sind auch nicht sehr groß. Bei den neuen Plänen kämen nur vielleicht 3 Tabellen hinzu und es fallen auch nur 1 Datensatz in der Haupttabelle und max. 5 Datensätze in einer Detailtabelle an. Ich muß lediglich die entsprechenden Vorgaben machen. Mit den Grundlagen des Datenbankdesigns kenne ich mich auch ganz gut aus, auch mit Access und SQL Grundlagen komme ich klar. Mir fehlen halt nur die Programmierkenntnisse und die Erfahrungen, wie man so was praktisch umsetzt.
Soweit ich es allerdings verstanden habe, könnte man doch auch die SQL Anweisungen direkt im Delphi starten.
Die einzige Frage, die sich mir stellt, ist, ob ich die jetzige Anwendung anpassen lasse oder die Anbindung an die Zentraldatenbank mit einer neuen Lösung zusätzlich programmiert wird.
Gruß Tilo