flashpixx

Jo, nicht valide Dokumente wird auch der beste Parser nicht verarbeiten können. Wenn man XML einsetzt, sollte man sich dessen bewusst sein (ich verkneif mir mal den sarkastischen Spruch bezüglich Deiner Daten, aber ich kann das Problem sehr gut nachempfinden)

sollte eigentlich kein Problem darstellen, definiere Dein eigenes XML Format was Du liest und überführe die Daten-XML via XSL Transformation mittels XQuery und The SAXON XSLT and XQuery Processor in Dein Zielformat. Du musst lediglich für jede XML eine Transformation erstellen, die in Dein Format transformiert. Die sollte aber deutlich flexibler / schneller machbar sein, als den DOM einzeln zu verarbeiten, d.h. in Deinem Fall definiere Dein XML Format, erzeuge dazu eine passende XSD, transformiere diese mittels JaxB in Java Klassen für das Marschalling. Schreibe eine XSLT, die die Daten-XML in Dein Format transformiert (ggf vice versa, damit Du Deine Daten wieder zurück transformieren kannst). Die XSLT holt sich dann mittels XQuery die entsprechenden Daten aus der XML und baut sie entsprechend zusammen. Mit den genannten Tools lassen sich solche Transformationen meist sogar per Drag-and-Drop erzeugen.

Ohne jetzt Deine Daten zu kennen, aber wenn DTD bzw XSD nicht valide ist, dann ist klar, warum es knallt. Ich würde wohl da ansetzen, dass ich mal schauen würde, woher die Invalidität kommt, d.h. also am Erstellungsprozess der DTD schauen. Jedenfalls habe ich auch schon die Erfahrung gemacht, dass XML Dateien schnell per String-Concatination "mal schnell" erzeugt werden. Die Begründung ist dann meist "ist ja nur Text mit so komischen Tags drin". Siehe z.B. Dokumenttypdefinition dort steht, dass das Feld auch Infos für den Parser enthalten kann, ich würde mal darauf tippen, dass in Deinem Fall die Daten, die in dem Feld stehen eben als Parseranweisungen interpretiert werden. Ich würde auch da wieder ganz klar der Definition folgen. Es ist immer ein guter Ansatz dort zu beginnen, wo die Definitionen herkommen (sofern sie automatisch erzeugt werden). P.S. Der Link zu Altova XMLSpy. Ich kann definitiv während des Designprozesses dazu raten, solche Tools einzusetzen, weil es einmal die Arbeit enorm unterstützt und eben dazu führt, dass invalide Strukturen vermieden werden.

Regulärer Ausdruck Pattern (Java 2 Platform SE v1.4.2)

Vielen Dank, da freue ich mich

Fein. Brauchst Du die DTD? DTDs sind nicht so flexibel bzw. umfangreich wie eine XSD, d.h. ich würde darauf verzichten und alles als XSD beschreiben. Ich würde falls der Inhalt der DTD notwendig ist einfach das in die XSD übertragen. Es klingt danach als sei die DTD nicht valide. javax.xml.bind.UnmarshalException - with linked exception: [java.io.FileNotFoundException: \C\Workspace\j2ee\ws1_test_jsf\BvXmlImporter\src\diebank.dtd (Das System kann den angegebenen Pfad nicht finden)] Generell werden Pfadangaben als URI via / getrennt und nicht \ Schau unbedingt in die Definitionen, ich denke das Problem wird daran liegen, dass Du die Sachen nicht korrekt definierst. Ansonsten rate ich ganz dringend zu entsprechenden Werkzeugen, die den Designprozess unterstützen z.B. AltovaXML oder XML Editor letzteres setze ich seit Jahren ein

siehe Ways to share an Access database - Access - Office.com Ich rate aber ganz dringend davon ab, soweit ich mich erinnere rät MS selbst davon ab, die Datenbank als "Shared Medium" zu verwenden. Nimm ein DBMS Deiner Wahl (ob mySQL geeignet ist, kommt auf die Datenbank an, Oracle, Postgres, MS SQL wären auch Alternativen) und übertrage die Struktur & die Daten. Das Reporting lässt sich mit Werkzeugen wie JasperReports Crystal Reports oder List & Label machen.

Das W3 definiert den Standard, d.h. dies sollte für Dich bindend sein und nicht irgendwelche anderen Seiten. Es gibt für Schemata zwei Versionen, wie Du Deinen Links entnehmen kannst. Ich habe auf Version 2 verlinkt. Für die Lösung Deines Problems müsstest Du nur die Dokumentation lesen z.B. das Kapitel "A Schema for Datatype Definitions (normative)".

Ich habe nicht geschrieben, dass Du die XSD generieren lassen sollst, sondern aus der XSD Java Klassen generieren sollst. Dies setzt natürlich voraus, dass die XSD fehlerfrei ist. Die Fehlermeldung ist doch eindeutig, entweder falsche Position des Elements bzw es ist zu häufig verwendet. Ansonsten solltest Du die Spezifikation lesen XML Schema Part 2: Datatypes Second Edition

Lass Dir aus der XSD die Java Klassen via Java Architecture for XML Binding erzeugen, compiliere sie und dann kannst Du via Marshalling / Unmarshaling die Daten als Objekte repräsentieren bzw. serialisieren. Du solltest keine Klassen von Hand erstellen, das führt fast immer zu Inkonsistenzen und damit zu Fehlern im Code

Lies Deinen Text vollständig, es steht dort sogar explizit drin und schwammig ist dies nicht Von Preis wurde nie gesprochen, in Deinem ersten Post ist dieser nicht erwähnt, aber ich denke, bei einer Datenbank für einen Gastronomiebetrieb kann ich durchaus voraussetzen, dass der Datenbankdesigner durchaus mitdenkt. Sorry, dass ich das sage, aber ich gewinne den Eindruck, dass Du mit aller Macht einen Grund suchst, warum Du die Aufgabe nicht lösen konntest. Einen Korrektor der Aufgabe wird das nicht interessieren, denn eigentlich wissen die Leute, die solche Aufgaben formulieren, was sie tun, d.h. wenn Du es nicht lösen kannst, dann wird es sehr wahrscheinlich an Dir liegen

Du hast die Entitiy "Bestellung" nicht erstellt und damit nicht heraus gefunden wo die n:m Beziehung liegt, ebenso fehlt dann auch noch die Übertragung der Entity via Normalisierung in Tabellenform, damit Du überhaupt einen SQL Statement erstellen kannst, denn eine n:m Beziehung kann man nicht direkt per SQL abbilden.

Ich geb' mal Wiki an, da das wirklich sehr gut erklärt ist: Lichtwellenleiter Die Antwort auf die Frage ergibt sich dann daraus

Es ist selten hilfreich eine fertige Lösung zu posten, vor allem wenn man nicht erklären kann, warum diese Lösung heraus kommt. Für den Fragesteller ist es sinnvoller sich mit Hilfestellungen eine Lösung zu erarbeiten und zu verstehen, warum dann diese Lösung heraus kommt. Deine fertige Lösung nimmt also jeden Lerneffekt.

Die Bestellungen fehlen, ansonsten wirklich bitte das ganze mal auf Papier aufmalen.

Stell mal alle Entities auf, da fehlen ja noch ein paar.

Da schließe ich mich an, wenn das "intern" ist, kann man das machen bzw. wenn der Zweck begrenzt ist. Auch dem stimme ich zu, aber Du hast ja dabei eine knapp definierte Anwendung. Ich habe in meiner Ansicht z.B. den alten DTA aus Einwohnermeldeämtern z.B. für die GEZ / Kirchen etc im Kopf. Ich poche nicht auf XML, sondern ich poche auf einer strukturierten & überprüfbaren Datenstruktur. Du kannst da auch JSON oder HDF nehmen.

Jain ETL ( ETL-Prozess ) sind zwar toolgestützte Prozesse, aber diese kann ich nicht flexibel in der Anwendung einbauen. Bei XML kann ich einfach durch eine XSLT Komponente den Transformationsprozess automatisiert durchführen (und das auf jedem System, da XML / XSLT Bibliotheken heute fast überall vorhanden sind). Z.B. hätte ich jetzt kein ETL Tool auf meinem OSX oder Linux direkt zur Verfügung, womit ich Transformieren kann. LibXML ist aber bei mir auf beiden System vorhanden und ich kann sie direkt entsprechend in meiner Software anbinden (analog MS XML via COM) [mal von der Lizenz und Nutzung des ETL Tools in eigenen Programmen mal abgesehen]. Auch die Aussage, dass das ETL Tool die "Transformation" beherrscht ist, halt ich für sehr gewagt, denn das ETL Tool setzt das Wissens des Users voraus, d.h. der User muss wissen in welchem Feld welcher Typ der Daten steht und wie diese zu interpretieren ist. Bei XML benötige ich diese Information nicht, da sie durch die XSD definiert ist, die mir zentral via URL vom Entwickler bereit gestellt werden kann. Wie man das so schön beim so genannten DTA (Datenträgeraustausch) hat(te), dass man seitenweise in Papierform die Definition der CSV bekommt, diese dann ggf in ein ETL Tool oder in Code übertragen muss, entfällt bei XML. ETL sehe ich aber nicht im Sinne von CSV, sondern es beschreibt den Vorgang der der Datenübertragung und -transformation, d.h. in einem ETL Prozess würde durchaus XML / XSLT verwendet werden können. Die Tools selbst bietet natürlich für Altsysteme auch den CSV Import an. Bei CSV kann ich die Transformation in keiner Weise "abstrakt" im Sinner einer Modelltransformation beschrieben werden, da bei CSV die Strukturinformation nicht an die Daten gebunden ist. Strukturinformation und Daten sind bei CSV völlig unabhängig, die Verbindung muss zwingend der Benutzer machen.

XSLT Schemata könne mit entsprechender Toolunterstützung auch schon automatisiert erstellt werden, da es letztendlich auch XML ist. Nein, das ist definitiv der Deine individuelle Meinung. Wenn ich real durchrechne wie hoch der Zeitaufwand von Anpassung des Codes über den Zeitraum der Nutzung ist und vor allem wenn ich die Metrik (z.B. Halstead / LLOC Metrik) des Importcodes bestimme, dann ist alleine durch die Metrik belegbar, dass CSV die schlechte Wahl sowohl wirtschaftlich wie auch fachlich ist. Natürlich setzt XML ein höheres Abstraktionsvermögen an den Entwickler voraus und Du magst recht haben, dass man "schnell mal nen CSV Code zusammen hacken kann" (auch diese Argumentation ist mir bekannt). Auch aus meiner Erfahrung kenne ich den Ansatz, dass man lieber CSV nimmt, weil Programmierer das eben mal schnell in 2 Stunden runterhacken und dann wenn was dran ist schnell nachpflegen kann (da wird gerne das "Eh-Da-Prinzip" angewendet). CSV ist somit ein "Dirty-Hack" ohne Struktur. Man sieht in solchen CSV Importen immer tonnenweise If-Bedingungen, wenn verschiedene Versionen der CSV unterstützt werden müssen, was aber dann zu einer schlechten Metrik führt, da mehr Lines-of-Code produziert werden müssen. Zusätzlich ist keine Typgebundene Struktur der Datenfelder möglich, d.h. es muss manuell konvertiert werden, was letztendlich extrem fehleranfällig ist, wenn in einem Feld in Abhängigkeit von der CSV Version unterschiedliche Typen benutzt werden. Zusätzlich ist ein sehr großes Problem bei CSV das Encoding der Daten, denn häufig wird hier einfach das Default-Encoding verwendet. Gerade bei der Darstellung von Umlauten (UTF-8/16 mit BOM Codierung) entstehen dann sehr interessante Effekte, die dann wieder "manuell" per Code abgefangen werden müssen, was die Metrik weiter verschlechtert. Natürlich kostet der höhere Strukturaufwand mehr Wissen, aber die Effizienz, die durch Metriken belegbar ist, kann gesteigert werden. Ich kann die Nodes eines XML Baums via XQuery direkt holen (inkl Filter und Sequenzen), mit Hilfe der XSD habe ich Validierung und direkt Typenkonsistent dabei. Ich kann für jede Version, die ich importiere eine eigene XSLT / XSD hinterlegen, so dass ich lediglich nur diese bei einer neuen Version anpassen muss. Ich habe die Möglichkeit die XML Verarbeitung in generische und versionsabhängige Strukturen zu trennen, so dass ich Anpassungen minimieren kann. Zusätzlich ist die Toolunterstützung bei XML sehr gut, bei CSV gibt es keine Toolunterstützung. Zusätzlich ist die Anpassung eines Schemas / XSLT deutlich einfache, da im Gegensatz zu Code kein Compilieren bzw. Linken notwendig ist. Der Austausch eines Schemas ist letztendlich der Austausch einer einzelnen Datei. Der Austausch von Code kann unter Umständen auch riskant sein, denn es müssen die Abhängigkeiten der Codestrukturen beachtet werden (Funktionssignaturen etc), somit ist die Anpassung eines Schemas schneller und nicht so fehleranfällig. Die Aussage, dass mit Kanonen auf Spatzen geschossen wird, ist definitiv falsch. Wenn man CSV einsetzt, dann ist das Kind sprichwörtlich in den Brunnen gefallen, denn das ist definitiv ein Fehler im Designkonzept, dass dies natürlich dann hohen Aufwand zur Korrektur bedeutet, ist klar. Würde man aber zu Beginn der Entwicklung eben auf XML Technologie setzen und darauf dann auch das Design aufbauen, wäre für einen CSV Export lediglich nur der Entwurf einer passenden XSLT notwendig, d.h. von XML nach CSV zu kommen ist einfach, umgekehrt dagegen schwer. Damit ist der Export der Daten direkt wesentlich generischer und damit auch flexibler. Wenn jemand CSV haben, dann kann er sich diese erzeugen. Wenn jemand HTML möchte, dann geht auch das; mit CSV nicht möglich. Eine fehlerhafte Planung wird man niemals wieder ohne bzw. mit wenig Aufwand korrigieren kann. Der Designfehler ist letztendlich dadurch gegeben, dass eben ein unstrukturiertes Datenformat vorliegt. Bekomme ich eine CSV ist es mir nicht möglich zu validieren, ob ich sie richtig gelesen habe. Bei XML ist dies möglich, da ich die XSD als Entwickler sogar zentral im Web ablegen kann. Das Argument bezüglich der Datengröße ist heute kaum relevant, da genügend Bandbreite zur Verfügung steht (eine Ausnahme mögen hier numerische / vektorielle / Matrizen / Hypercubes sein, aber davon gehe ich jetzt nicht aus). Generell gilt aber, die Struktur der Daten muss abstrakt überprüfbar sein.

Man kann CSV nicht abstrakt validieren, d.h. ich muss Code schreiben, um die Struktur zu verarbeiten bzw. zu prüfen ob sie korrekt ist. Bei XML mit XSD kann ich die Validierung automatisiert erledigen mit Hilfe von XSLT kann ich dann die XML beliebig transformieren. Eine Veränderung der Struktur der CSV zieht somit automatisch eine Veränderung des Codes mit sich. Codepflege ist aufwendig und fehleranfällig. Bei einer XML wäre hier lediglich eine Anpassung der XSLT notwendig, um eine neue Version der CSV zu verarbeiten. Mit Strukturen wie XML, XSD und XSLT ist die Pflege deutlich einfacher und der Code erhält eine höhere Abstraktion. Analoges gilt natürlich für JSON. Für die XML / JSON Verarbeitung gibt es entsprechende Bibliotheken, die seit Jahren getestet und optimiert sind, so dass auch die Fehleranfälligkeit weniger sein wird. Für einen Import dieser Daten muss dann lediglich die XML via XSD validiert werden, damit ist direkt möglich zu prüfen, ob die Struktur korrekt ist, nun kann man mit Hilfe von XQuery in den Nodes suchen und muss lediglich über die gefunden Nodelisten iterieren, d.h. hier ist eine deutliche Codereduktion möglich. Falls man das ganze noch weiter abstrahieren will, setzt man eine XSLT dazwischen, die eine Transformation des XML Baumes durchführt. mit Hilfe der XSLT kann man somit unterschiedliche Versionen der XML verarbeiten, so dass die Pflege und Weiterentwicklung des Importes besser wird.

Ich rate noch einmal ganz dringen von diesem fachlich schlechten Ansatz ab. Ein Pseudo-Code (dies ist kein(!) lauffähiger VBA Code) löst dieses Problem emailempfaenger = ["mMustermann1@Test.de"] if audit : emailempfaenger.extend(["mMustermann2@Text.de", "mMustermann3@Text.de"]) write email with BCC recipients " ".join(emailempfaenger) Ich erzeuge eine Liste mit den Empfängern, wobei ich die Personen, die immer eine Nachricht erhalten sollen direkt in der Liste anlege und dann prüfe ich ob ein Audit vorliegt (audit ist als Boolean aufzufassen), wenn ein audit == true ist, dann ergänze ich die Liste. Danach implodiere ich die Liste zu einem String, den ich als BCC verwende. Du solltest bei solchen Dingen definitiv den BCC verwenden und eine korrekte Rückantwortadresse verwenden, dies ist ein allgemeines Vorgehen bei Mailinglisten. Sorry für das F'Quote, aber wenn Du nicht das notwendige Wissen hast, den Code den Du produzierst zu verstehen, dann kannst Du die Problemlösung nicht beheben. Du musst Dir das notwendige Wissen aneignen. Ich rate Dir aber von Deinem Vorgehen ab, nimm ein fertiges System, das Mailinglisten verwalten kann (Links siehe mein erstes Post), damit hast Du all diese Probleme nicht. Alternativ pass den MTA so an, dass er die Daten direkt verarbeiten kann, d.h. die Daten die jetzt in der Exceldatei gespeichert sind werden in eine Datenbank gelegt und anhand dieser liest der MTA die Mailadressen und leitet die EMail direkt an die entsprechenden Personen, sobald sich dann etwas in den Daten ändert, ist die Änderung auch direkt bei den Mailadressen konsistent. Eine Mailingliste aufzusetzen sollte für einen Administrator nur einige wenige Minuten Arbeit sein.

Ganze ehrlich klinkt das klingt nach Fummelei. Ich rate zu einer richtigen Liste (serverseitig), d.h. die Leute, die angeschrieben werden sollen stehen in der Liste und ich kann dann eine EMail an "meineliste1@wasauchimmer.de" schicken und die EMail wird an alle weiter geleitet. Eins der bekanntesten System dafür ist Majordomo bzw. Mailman Vor allem wird hier auch direkt passend die CC/BCC Info gesetzt und auch die Antwortadresse. P.S.: Verwende bitte für Codes die Code-Tags

Eine CSV Datei ist im Grunde ein unstrukturiertes Datenformat, wenn Du dieses ändern musst, pass den Export an oder schreibe ein Programm in einer Sprache Deiner Wahl, dass die CSV Datei entsprechend umstrukturiert. Ich raten dringend dazu, dass man von so einem Format dringend Abstand nimmt, denn es macht letztendlich mehr Probleme. Ich rate zu einer Datenbank oder XML mit Validierung durch XSD

Ich finde das was @blubbla geschrieben hat sehr treffend formuliert. Ich kann dem in allen Punkten nur zustimmen, vergleiche ich Schule, Ausbildung, Beginn des Studiums und jetzt, dann liegen dazwischen Welten, aber ich halte gerne Vorträge und meine Zuhörer scheinen eigentlich immer motiviert zu sein. Das was ich aber gelernt habe ist, dass man es einfach locker angehen sollte, d.h. das man sich mal verspricht oder verschreibt (passiert mir ab und an bei Formeln) ist völlig normal, ich bin auch schon mal über das Stromkabel gefallen. Passiert halt. Das was ich immer mache ist, dass ich meine Folien selbst erstelle, also z.B. nicht vorbereiten lasse, ebenso überlege ich mir selbst was ich zu welcher Folie sage, ich nutze gerne die Funktion, dass ich Moderatornotizen mir auf dem Laptop anzeigen lassen kann. Ist für mich lediglich der Hinweis, dass ich nichts wichtiges in der Folie vergesse. Zusätzlich sind meine Folien recht kompakt, max 3 Stichpunkte und oft ein verdeutlichendes Bild daneben. Ich lese die Folien nicht ab, sondern erzähle etwas dazu, d.h. die Folien sind der rote Faden des Vortrages, aber viele Infos kommen eben mündlich dazu. Ich rechne ca pro Minute eine Folie, das passt bei meinen eher mathematischen Themen recht gut und ist an manchen Stellen schon hart an der Grenze, weil ich dann durchaus ein hohes Tempo habe, wenn man von 30 Minuten Vortrag ausgeht. Es hilft deutlich, wenn Du Dir einfach denkst, Du erzählst den Leuten etwas, was Du alleine gemacht hast (d.h. selbst anständig auf das Thema vorbereiten und auch davon ausgehen, dass Querfragen kommen). Du bist derjenige der Ahnung von dem Thema hat, d.h. Du willst allen einen schönen Einblick in das Thema geben. Man wird sicher nie alle Fragen im Detail beantworten können, d.h. da sollte man dann ehrlich sein und sagen "weiss ich im Moment nicht, kann ich aber bis morgen nachschauen". Viele tendieren häufig dazu dann, dass sie versuchen, das Nichtwissen zu verschleiern, das ist der falsche Ansatz. Geh einfach locker in den Vortrag und denk Dir einfach, dass Du nem Kumpel eben etwas erzählst.

von diesem Vorgehen würde ich dringend abraten, das ist mehr ein "dirty hack". Installiere das Programm als Dienst mit den entsprechenden Rechten, d.h. der Dienst braucht die passenden Rechte. Ein normaler User hat nicht die Berechtigung Dienste zu verändern. Dein Programm braucht dann kein Passwort o.ä., da der Dienst von sich aus die passenden Rechte hat und damit auch das Programm. Wann der Deinst laufen soll, kannst Du in den Eigenschaften des Dienstes dann auch fest legen.