flashpixx

Nein, wenn man einen Cursor benutzt ist das überflüssig. In Deinem Fall nutzt man einen Cursor, so dass Änderungen am Datensatz direkt übernommen werden

Du kannst in ein Formular ein Subformular aufbauen, d.h. das Formular wählt die Datensätze der Customer aus und im Subformular werden die Datensätze aus Checks angezeigt. Alternativ baue eine entsprechende Abfrage, die beides direkt enthält und binde diese als Formular ein.

Wie man Fragen richtig stellt: eine Anleitung wie man Fragen erfolgreich in Usenet, Mailing Listen und Webforen stellt.

Ich bezweifle, dass es so etwas gibt, denn woher soll eine Software wissen mit welcher Wahrscheinlichkeit irgendeine Komponente ausfällt. Die Ausfallwahrscheinlichkeit ist von so vielen Faktoren abhängig, dass man dieses kaum in eine Software hinterlegen kann. Weiterhin werden individuelle Strukturen (z.B. bauliche Gegebenheiten) nie berücksichtig werden können. Zusätzlich führt ein Ausfall einer Komponente nicht zwingend zu einem Ausfall des Gesamtsystems, dies ist abhängig z.B. von Switches und eben der realen Verkabelung und Konfiguration (Stichwort Spanning Tree Protocoll & Redundanz). Eine präzise Bewertung der Komponenten ist nur durch eine empirische Stichprobe bzw mehrere Stichproben möglich und aufgrund dessen kann man dann selbst die Wahrscheinlichkeiten und die Verteilungsfunktionen approximativ ermitteln.

Lua: documentation hättest Du auch selbst finden können.

Man wählt die Sprache nach der Problemstellung. Oft wird aber eine Sprache gewählt, die man immer benutzt, eben mit der Begründung "man kann sie". Im Grunde kann man jede Sprache verwenden, nur ist es oft möglich durch eine sinnvolle Sprachwahl sich die Arbeit zu erleichtern. Meist ist aber ein etwas abstrakteres Vorgehen sinnvoll, denn damit werden die Scripte durchaus portabel und leicht erweiterbar. Man kann eben durch "schnelles Hinfrickeln" durchaus etwas brauchbares erreichen, hat aber dann evtl später mehr Zeit- und Korrekturaufwand um Änderungen hinzuzufügen oder man steckt eben zu Beginn die Zeit in eine etwas universellere Lösung, dann sind Anpassungen aber leichter und schneller. Z.B. man muss diverse Logdaten (TXT, XML, SNMP) auswerten und soll sie zur Auswertung in eine zentrale Datenbank schreiben, nun hat man noch unterschiedliche Server (diverse Windows Versionen, BSD und Linux). Man kann jetzt hingehen und für jedes System einen individuelles Script schreiben oder man nimmt eine Sprache mit der man eben ein Script schreibt bei dem lediglich nur die Pfade zu den Logdateien angepasst werden müssen. Zusätzlich braucht man noch einen XML Parser, einen SNMP Client, Tools für reguläre Ausdrücke, für MS Systeme die .NET Anbindung und eben einen passenden Datenbankclient. Lua würde das alles schon fertig mitbringen, zusätzlich für die Windows-Welt wäre eine Anbindung via LuaInterface an die MS spezifischen Komponenten möglich. PowerShell unter unixoxiden OS dürfte wohl etwas schwer werden und ein Bashscript würde nur in der Windowswelt mit Cygwin o.ä. gehen.

evtl wäre Lua auch sinnvoll, da es extrem schlank ist, nur der Interpreter installiert sein muss und recht viel schon Hause aus mitbringt (Datenbanken, Socket, Netzwerk und auch Anbindung zu .NET)

geht auch alles in eine Seite prüfe get wenn Parameter angegeben generiere Form mit Parameter andernfalls generiere Form ohne Parameter wenn Parameter vorhanden dann führe mysql aus erzeuge Ausgabetabelle Du solltest Post und Get nicht unbedingt mischen

Du solltest verstehen was Du programmierst. PHP: $_GET - Manual PHP: $_POST - Manual Du verwendest schon Post, d.h. Du musst Dir nur überlegen wie Du das entsprechend umschreibst. Parameter, die an der URL stehen, werden via $_GET gelesen, d.h. Du musst prüfen, ob diese Parameter gesetzt sind, wenn ja, nimmst Du diese direkt und arbeitest mit denen, wenn nein, dann zeigst Du einfach Dein Formfeld an. Wenn Du nun festgestellt hast, dass Parameter an der URL hängen, kannst Du diese in den HTML Code einbinden siehe dazu SELFHTML: HTML/XHTML / Formulare / Eingabefelder und Eingabebereiche sprich Du musst nur den HTML Code passend mit den Parametern zusammenfügen.

Nimm anstatt einer statischen HTML Seite eine PHP Seite und greife die via Get übergebenen Daten ab und fülle sie in die Felder des durch die PHP Seite erstellten Formulars (anhand der Daten kannst Du natürlich auch den Datensatz laden)

Nein, die CRC Summe bezieht sich auf den Inhalt des Paketes ( User Datagram Protocol ), d.h. Du kannst damit Prüfen, ob das Paket korrekt übertragen wurde. Du kannst aber nicht entscheiden, ob die gesamte Datenübertragung korrekt ist. Sich sende Dir 1,2,3 + Prüfsumme, d.h. 4 Pakete, wenn nun aber nur 3 Pakete ankommen, dann kannst Du nicht entscheiden, ob das letzte Paket ein Datenpaket oder ein Prüfsummenpaket ist. Wenn ich annehme, dass alle 4 Pakete eingehen z.B. in der Reihenfolge 1,Prüfsumme,2,3 dann würdest Du annehmen, dass das letzte Paket das Prüfsummenpaket ist, wäre es aber nicht. Selbst wenn Du alle Pakete bekommst und Du die Prüfsumme bildet und die Prüfsumme falsch ist, kannst Du nicht sagen, welches Paket Du vom Client noch einmal anfordern musst, denn es existiert keine Ordnung in den Paketen, d.h. wenn die Prüfsumme inkorrekt ist, musst Du die ganze Übertragung noch einmal durchführen und das ist extrem ineffizient. Bei TCP weisst Du anhand der Sequenznummer welches Paket noch einmal angefordert werden muss. Und was passiert, wenn der Client trotzdem sendet !? Ein Paket wird eingehen, sprich in diesem Fall wird bei Dir ein neuer Thread erzeugt und gedanklich ein neuer Clientzugriff generiert, in diesem Fall ist das Problem aber, dass die Daten die ankommen nicht zugeordnet werden können. Mir ist das Prinzip der Übung schon klar, nur solltest Du evtl mal mit Deinem Prof darüber sprechen.

Nehmen wir mal den Fall an, der Client initiiert die Kommunikation, der Server erzeugt seinen Socket und bekommt das erste Paket vom Client, sendet sein Ack zurück, aber das kommt beim Client nicht. Der Client sendet dann noch einmal das gleiche Paket. Der Server kann in dieser Konstellation nicht entscheiden, ob die Daten, die er da ein zweites Mal bekommt nicht schon erhalten hat (Stichwort: Sequenznummer). Diese Duplikate können auch bei schlecht gewählten Timeouts statt finden, da Client und Server nicht synchronisiert sind. Als weiterer Punkt: UDP ist verbindungslos, d.h. wenn ein Paket gesendet wurde, hat das System keine Kenntnis von weitere Kommunikationsstruktur. Eine Datei wirst Du sicher nicht in einem einzelnen Paket unterbringen können, d.h. für den Server sind das erst mal unabhängig eingehende Pakete (Stichword: iid). Sprich wenn ich einfach UDP Pakete generiere und an Deinen Server schicke und diese zufällig mit Daten fülle, dann werde ich Deinen Dienst garantiert überfordern können, denn der Dienst verhält sich wie eine Warteschlange. Da Du jedes eingehende Paket entsprechend in eine Ordnung überführen musst und eben bei der Dateiübertragung dann in den passenden Filestream schreiben musst. Als Bsp ich sende Dir 1000 Initialisierungspakete, dass ich Dir 1000 Dateien senden möchte, Dein Server muss die Acks genieren und ich sollte dann darauf passend die Datenpakete senden, was ich aber nicht mache. Dann hat Dein Server 1000 offene Verbindungen und kann nicht entscheiden, kommen da noch Daten oder nicht. Nun initialisiere ich noch einmal 1000 neue Verbindungen.... (Stichwort Denial of Service ). Dein Dienst schreit förmlich danach ihn lahm zu legen.... Bei TCP kann der Server entscheiden, wenn noch einer gewissen Zeit keine Daten mehr rein kommen, dass er einfach die Verbindung trennt. Der Client wird dies dann gemeldet bekommen.

Das nützt Dir nichts, denn es ist nicht garantiert, dass a) jedes Paket was der Client an den Server sendet überhaupt ankommt, d.h. die CRC Summe wird ggf auf dem Server eine andere sein, wie auf dem Client und die Reihenfolge der Pakete ist nicht garantiert, d.h. wenn die Pakte 1,2,3 vom Client abgesendet werden, können am Server die Pakete 2,1,3 ankommen, was dann zu einer anderen CRC Prüfsumme führt, aber c) Du kannst das überhaupt nicht prüfen, denn wenn Du die CRC Prüfsumme vom Client zum Server überträgt ist auch nicht garantiert was am Server ankommt, d.h. die CRC Prüfsumme die der Server aus seinen empfangenen Daten berechnet und die CRC Summe, die Du auf dem Client berechnest können selbst bei gleichen Daten unterschiedlich sein oder eben bei unterschiedlichen Daten gleich. Das Verhalten ist bei UDP nicht deterministisch, somit ist eine Datenübertragung per UDP fachlich völlig sinnfrei. Für Datenübertragung ist es essentiell wichtig, dass garantiert ist, dass jedes Datenpaket zwischen zwei Endpunkten ankommt und zusätzlich muss garantiert sein, dass die Reihenfolge (Ordnungsrelation) erhalten bleibt. UDP wurde primär für Datenstreams entwickelt, bei denen es keine Rolle spielt, ob ein Paket ankommt oder nicht. Ich empfehle Dir, dass Du einmal die netzwerktechnischen Grundlagen anschaust, bevor Du es versuchst etwas zu programmieren.

User Datagram Protocol Für einen Dateitransfer ist UDP somit das falsche Protokoll

Nein es findet kein Listen statt. Der Client connected, ein neuer Thread wird erzeugt. In dem Thread teilt der Server dem Client z.B. einen dynamischen Port zu, Client und Server verbinden. Server und Client kennen den Port auf dem sie sich verbinden, d.h. Du musst nicht suchen und er muss auch nicht darauf warten, ob da eine Verbindung kommt. Lass diese ganze Portsuche weg. Der Client connected, der Server erzeugt beim Connect des Clients einen neuen Thread mit einem Socket drin, d.h. Du hast eine Punkt-zu-Punkt Verbindung zwischen Server & Client über die Du Daten übertragen kannst. Gibt es einen Socketfehler oder eben die Datenübertragung ist beendet, wird der Socket geschlossen und der Thread beendet. Dynamische Portverwendung brauchst Du letztendlich nur, wenn der Server eben gewisse Anforderungen bereit stellen muss. Du braucht bei einem einfachen Serverdienst genau einen Port.

lies bitte mein vorhergehendes Post er kann einen neuen Port verwenden er muss es aber nicht Du kannst einen Port verwenden und jedes Mal wenn ein Client auf einem definierten Port connected wird ein neuer Socket in einem neuen Thread erzeugt, über den die Daten ausgetauscht werden (Socket != Port), d.h. Du hast einen Masterthread laufen über den der Verbindungsaufbau statt findet, wenn nun eine Verbindung eingeht, wird ein neuer Thread erzeugt, in dem wiederum ein neuer Socket erzeugt wird. Wird der Socket geschlossen, wird der Thread beendet. Sprichwörtlich wird somit jeder Connect eines Clients über einen Thread und einen Socket realisiert.

Du braucht nicht jedes mal einen neuen Port zu verwenden, ein Socket reicht. Der Server erzeugt nachdem der Client verbunden ist einen Socket in einem neuen Thread, d.h. der Client hat einen neuen Socket und der Server dazu auch, d.h. der Server kennt über das Socketobjekt den Client. Wie man nun Threading im Detail implementiert und ob man evtl dynamische Ports (neue Ports vergibt) kommt auf die Kommunikationsdetails an.

Nein im Normalfall hat man den Server auf einen Port gebunden, d.h. auf diesem hört der Server eingehende Nachrichten, wenn nun eine Nachricht kommt, dann teilt der Server dem Client nur einen "zufällig" gewählten Port > 1023 mit und der Client kommuniziert dann mit dem Server über diesen Port. Damit hat jeder Client seinen eigenen Port / Socket und dieser Vorgang wird in einen eigenen Thread verlagert.

Der Socket identifiziert den Client, d.h. anhand des Socket weisst Du welcher Client verbunden ist

Ergänzend dazu: Deshalb verschlüsselt man Verbindungen, zusätzlich sollte nicht jeder wildfremde Client eine Verbindung zur Datenbank aufbauen und zusätzlich kann man durch entsprechende ACLs auf den Routern Zugriffe von unbekannten Quellen absichern. Im Normalfall kommt a) nur eine explizit freigegebener Client (Subnetz / statische IP) eine Verbindung auf den Datenbankserver, die Datenbank authentifiziert den User anhand Zertifikat oder Username & Passwort und anhand der Client IP / Subnetz und c) jede Verbindung zum Datenbank geschieht über eine verschlüsselte Verbindung. D.h. der Datenbankdienst kann anhand der IP des Client und der Userinformationen entsprechende Statements unterbinden. Wenn die Authentifizierung am Datenbankserver unverschlüsselt statt findet und/oder jeder connecten darf, dann würde ich vielleicht erst einmal Gedanken in eine sichere Netzstruktur investieren, anstatt irgendwelche Filter zu implementieren. Zusätzlich sollte es nicht jedem User möglich sein, auf das OS des Datenbankservers zu kommen, also ein Datenbankserver auf dem noch zig andere Dienste laufen und jeder User remote connecten darf, ist natürlich ein potentielles Sicherheitsrisiko. Ein Datenbankserver stellt nur den Datenbankdienst zur Verfügung und nur ein entsprechender Administrator aus einem entsprechenden Netz darf sich auch nur mit einer verschlüsselten Remoteshell verbinden

Man kann nicht nur aufgrund von Logindaten beschränken, sondern auch von Hostdaten, d.h. Änderungen der Daten sind von bestimmten Hosts verboten. Was bringt denn bitte ein solcher Schutz !? Du kannst z.B. ein Insert Statement innerhalb einer Stored Procedure so gar nicht abfangen, denn die SP wird innerhalb der Datenbank aufgerufen, d.h. Dein Filter würde da gar nicht greifen. Weiterhin sollte die Kommunikation zwischen Anwendung und Datenbank verschlüsselt ablaufen, d.h. Dein Filter kann gar nicht die Statements filtern, da die Daten verschlüsselt übertragen werden, das was da nur hilft wäre eine Man-in-the-Middle Attacke, aber das möchtest Du sicherlich nicht. Mach ein entsprechendes Host & Userkonzept, um zu entscheiden welche User von welchem Host entsprechende Zugriffe brauchen. Authentifiziere die User passend an der Anwendung, so dass die Anwendung mit dem spezifischen Useraccount auf der Datenbank arbeitet, vergib anständige Passwörter oder Zertifikate, sichere die Verbindung zwischen Anwendung und Datenbank per SSL ab, sichere die Anwendung gegen SQL Injections ab. Das Filtern von SQL Statements muss entweder dort geschehen, wo sie generiert werden, d.h. in der Anwendung oder eben durch entsprechende Rechte verboten / erlaubt werden, was dann auf Datenbankebene geschieht. Das was Du da machen willst, ist absolut fahrlässig, denn wenn ich z.B. ein codiertes SQL Statement in die Verbindung einschleusen kann, wird dein Filter ebenfalls nicht greifen. Die Anwendung (wobei Anwendung hier auch eine mehrschichtige Architektur sein kann, Frontend, Applicationserver, Datenbankserver) & die Datenbank sind die zwei Punkte, an denen man absichern muss, alles andere zeugt eigentlich davon, dass man sowohl auf Anwendungs- wie auf Datenbankseite keine ordentliche Absicherung hat

Erlaube dem User , der connected, einfach keine Veränderung auf Feld- & Tabellenebene, alles andere ist Frickelwerk.

Ack, nur hier soll ja im nur ein Tag entfernt werden und das geht mit regulären Ausdrücken, ansonsten nimmt man XSLT.

verbinde Dich mit dem alten Server und kopiere via IMAP die Daten auf den neuen.

Das ist doch per Definition korrekt, nur du hast hier keine Fläche sondern eine 1-dimensionale Größe (Breite)