Argbeil

DevCouch - Coole .NET Videotutorials: Home - DevCouch - der Autor ist ein cooler Typ!

Hallo du, ja, das ist möglich, du brauchst dafür auch keinen Wrapper. Deine Assembly muss für COM-Eports kompiliert und auch signiert sein. Du kannst sie dann mit regasm.exe wie einer normale COM-DLL registrieren.

Klar, ist kein Problem!

Ich bin der Überzeugung dass der erste Ansatz wesentlich mehr Nachteile bietet, bei der COM Variante fällt mir für diese Anforderung kein einziger Vorteil ein. COM Marshalling ist zur Laufzeit extrem langsam da der erzeugte Wrapper dynamische Invocation durchführen muss ( siehe hier ) und zudem den Excel Prozess erstmal hochfahren muss. Man hat eine extrem enge Bindung an Excel und in der Vergangenheit gab es da häufig Probleme wie Memory-Leaks die erst durch Service Packs gefixt wurden. Das Verhalten bei der Typ-Erkennung ist kein besonderes Problem. Da man die Struktur in Excel nicht erzwingen kann und der User auch in eine Währungsspalte "Hallo" schreiben kann, muss man jeden Wert sowieso erstmal als String behandeln und validieren. Zudem ist das ganze COM/Excel Konstrukt zum reinen auslesen von Daten völlig unnötig. Wenn man Excel-Dateien formatieren, erzeugen, ändern und speichern will macht das vielleicht Sinn - aber auch dafür gibts native .net Excel-File Komponenten. Der allerwichtigste Grund ist aber: Das System ist nicht Thread-Safe! In einer WebAnwendung würde das ganze ohnehin nicht funktionieren. Wird die Anwendung über Terminal-Services ausgeführt wird sie instabil, evtl. schon wenn sie mehrmals gestartet wird. Microsoft rät übrigens ohnehin ab Office Komponenten zur automatisierung zu verwenden. Quelle

Dann musst du aber drauf achten anstelle von UNION ein UNION ALL zu verwenden, anderenfalls werden identische Datensätze aus beiden Views nur einmal übernommen.

Hab die Anforderung nicht komplett verstanden. Willst du die Daten addieren? Also soll aus ColA1 = 2 und ColB1 = 5 dann eine 7 werden? Oder soll 2 und 5 hintereinander ausgegeben werden?

Jepp, würde ich genau wie Thomas machen. Über Integration Services die Daten laden, es gibt einen Wizard der aus dem SQL Server Management Studio heraus die IS-Pakete automatisch erstellt, SQL Server kann auch ohne Probleme auf Oracle zugreifen. Konsistenzprobleme treten nur dann auf wenn du nicht alle Daten importierst oder die Quelldaten während des Imports verändert werden.

Ja genau, Custom-Action erstellen welche die Dateien kopiert. Mal was anderes: Datendateien die vom Programm geändert werden, dürfen nicht im Programm-Files Ordner liegen.

little2k3 hat recht. Wenn du jetzt auf die Zellen uugreifen kannst, hast du eine Abhängigkeit zu Excel, vermutlich per COM Referenz? D.h. auf dem Rechner auf dem deine Anwendung läuft muss Excel installiert sein, evtl. auch noch in der richtigen Version. Bau lieber einen oledb Connection zu der Excel-datei auf, du kannst dann wie auf eine Datenbank per oledbcommand oder dataAdapter auf die Excel-Sheets zugreifen.

Solche Lösungen scheitern häufig an der Anwendungsarchitektur, in der Regel macht man sich die Parallelität durch locking wieder kaputt. Zudem hat man in deinem Anwendungsfall vermutlich weitere Probleme, die Datenmengen sind einfach zu klein und führen zu Locks auf Hardware-Ebene. Der IIS als Webserver kann die Requests ja auch schon von Haus aus auf verschiedene Cores verteilen. Ich würde dir empfehlen eine Architektur wie Event Based Components zu verwenden. Die Komponenten sind komplett statuslos und brauchen dadurch kein locking. Wenn die Anwendung erstmal ohne Threading fertig ist kann man jede einzelnen Komponente paralelisieren. Ich wage aber die Prognose das die parallele Lösung trotzdem langsamer laufen wird als die synchrone.

Um genau zu sein DARF in diesem Fall die ID auch nicht fortlaufend sein. Die ID ist die Identität deines Datensatzes, wenn du den Satz löscht darf ein anderer nicht die gleiche ID bekommen weil die Identität über den Zeitraum nicht mehr eindeutig wäre. Das erzeugt Probleme z.b. bei Paging in Anwendungen. Häufig referenzieren Anwendungen DataRows nur über ihre ID. Ein späteres UPDATE WHERE ID = ... könnte dir deinen neuen Datensatz verändern obwohl der alte gemeint war.

Kann mir jemand erklären was das Wort "Abhilfe" in dem Zusammenhang bedeutet? Ich kenne das nur aus Gesetzestexen ( Abhilfe ? Wikipedia )...aber ich kannte ja auch das Wort "Topiken" nicht. Das Ziel des Gesprächs aus Sicht des Unternehmens sollte sein dich als Bewerber gut einschätzen zu können, ich würde mich da nicht verrückt machen und ehrlich sein. Die Fragen die wirklich gestellt werden kann man eh nicht vorhersagen. Den Namen des Unternehmens hier zu posten ist übrigens nicht sooo clever. Ich drück die Daumen.

Da die Daten hier ja nach dem einlesen statisch sind sehe ich selbst bei MDS keine Notwendigkeit während der Visualisierung die kompletten Daten halten zu müssen, die nötigen Werte kann man vorberechnen. Aber ich glaube das war auch gar nicht das ursprüngliche Problem von Murli.

Um nochmal zum Ausgangspost zu kommen: Ich glaube nicht das eine allgemeine Datenbankzertifizierung etwas taugt. Bzw. was soll dein Ziel dabei sein? Wenn du dich mal irgendwo bewirbst zeigst du damit: Ich kenne mich allgemein mit Datenbanken aus, aber nicht mit einem bestimmten Produkt. Bei Firmen sind aber in der Regel nie "allgemein Datenbanken" vorhanden sondern immer Produkte wie Oracle, SQL Server, MySql, etc. so das eine bestimmte Produktzertifizierung für Firmen viel interessanter ist. Und ich vermute ach das jemand der z.B. eine Oracle Zertifizierung hat sich auch relativ schnell in SQL Server einarbeiten kann. Sowohl die Oracle als auch die Microsoft Zertifizierungen beschäftigen sich eingehend auch mit den Grundlagen von Datebankdesign, Normalisierung usw., die Preise richten sich danach ob du einen Präsenzkurs besuchen möchtest, Online Trainings oder Selbsstudium machst. Bei Microsoft ist die günstigste Variante immer das Buch zum Selbststudium (Self Paced Training Kit) + die Prüfung für ca. 200 Euro.

Meiner Meinung nach liegt das Problem darin begründet, dass der Content deines Array auf dem Stack und nicht auf dem Heap verwaltet wird. In dem Color Objekt befinden sich ja vermutlich int Werte - die Value-Types sind, bei solch einer Menge ist der Stack irgendwann natürlich voll. Ich würde mal drüber nachdenken ob du wirklich JEDEN erfassten Messpunkt wirklich brauchst, von Punkt 0 zu Punkt 1 sind ja evtl. gar keine großen Sprünge zu erwarten so das die Auflösung ggf. reduziert werden kann. Wenn jeder Punkt verarbeitet werden muss würde ich die Daten z.B. mit einem MemoryStream sichern. Der Stream liegt auf dem Heap, bei einem 32 Bit OS sollte die Grenze hier bei 2 GB liegen. Wenn die Daten größer werden musst du sie auf die Platte streamen. Wenn es nur um Visualisierung hatte ich noch nie einen Fall in dem die komplette Struktur auf einmal im RAM gebraucht wurde, mehr Daten zu halten als der Monitor auflösen kann macht keinen Sinn.

Um nochmal zur eigentlichen Frage zurück zukommen - was ist .NET? Wie einige schon schrieben ist .NET ein Framework und auch eine alternative zum COM, aber das sind alles nur einzelne Elemente. Ich denke, .NET muss man als ein Stück "Softwareinfrastruktur" betrachten. .NET ist auch kein einzelnes Produkt was man runterladen oder im Laden kaufen kann. Es besteht aus sehr vielen Komponenten, deshalb ist eine genaue Antwort auf die Frage ein Abendfüllendes Thema. .NET besteht unter anderem aus einer Assembler ähnlichen, typsicheren und Stack-Orientierten Sprache ( Intermediate Language, IL-Code ) die von einer Runtime Engine (Common Language Runtime) ausgeführt wird und Features wie Garbage Collection, Sicherheitsfeatures usw bietet. Die CLR besteht unter anderem aus einem Just-In Time Compiler der optimierten Maschinen -Code für die jeweilige Plattform erzeugt. Dazu kommt eine sehr mächtige Klassenbibliothek (.NET Framework) und diverse Compiler die den IL-Code erzeugen C#.NET, VB.NET, F#, ...

Wie bereits geschrieben.

Bei .NET ab Version 3.0 kannst du auch Linq2Xml verwenden um das "Xml Dokument" zu durchsuchen und dein Dictionary zu befüllen. Das laden kannst du über var xElement = XElement.Load(xmlDateiname); realisieren. Darauf kannst du dann ganz normale Linq Operationen durchführen. var applications = from item in xElement.Elements() select item.Element("APPLICATION_NAME").Value; Anstelle des select item .. kannst du an der Stelle auch sowas wie select new DictionaryItem(item.Element("APPLICATION_NAME").Value, ... ); verwenden um direkt an dieser Stelle das Dictionary aufzubauen. (Code ohne Gewähr und aus dem Kopf, aber das Prinzip sollte klar sein. Sonst einfach nach Linq2Xml suchen) Nebenbei ist das kein sehr schönes Xml Dokument weil die sich änderne Item-Nummber nicht als Attribut oder InnerText hinterlegt ist und so nicht bequem validiert oder ausgelesen werden kann.

Nich einfacher und vor allem ressourcenschonender: Beim starten des Programmes z.B. per DateTime.Now die aktuelle Zeit sichern, dann kann man später über DateTime.Now - startTimedie jeweilige Differenz als Timespan erzeugen und ggf. über ToString als String formatieren.

Mit dem .NET Framework 4.0 kannst du Anwendungen ausführen die für .NET 4 kompliert wurden. Mit dem Framework 3.5 laufen Anwendungen von 2.0 bis 3.5. .NET 4 ist zudem "weitgehend" kompatibel zu älteren Anwendungen, es gab allerdings Änderungen im Bereich Runtime Security und einigen weiteren Bereichen. D.h. das du selbst verantwortlich bist deine Anwendung mit der jeweiligen Framework-Version zu testen. Neues in .NET Framework 4 Du kannst in über das Supported-Runtime Element in der Konfiguration dann sehr genau festlegen welche Runtime Version deine Anwendung zwingend benötigt ( <supportedRuntime>-Element Meine Empfehlung ist die folgende: Wenn du eine .NET 4 Anwendung erstellst muss das Framework 4 installiert sein und alles ist gut. Wenn du Anwendungen ab Version 2 hast stell in Visual Studio die Target Version auf .NET 3.5 und setze die supportedRuntime auf 3.5. Für ältere Anwendungen muss das jeweilige Framework installiert sein.

Im Prinzip hast du bei deiner Lösung schon eine MVC Lösung, das Dataset ist das Modell, der DataAdapter ist der Controller und das Form ist der View. Jetzt muss du nur noch den Code auf mehrere Klassen verteilen, am besten du fängst mit der Controller-Klasse an und baust für jede mögliche Aktion in der GUI eine Methode in den Conroller. Leider ist das MVC Pattern in WindowsForms nicht sehr gut abbildbar, der View sollte die Möglichen Aktionen des Controllers selbst erkennen und anbieten, sowas kann man zwar lösen, mit Xaml/WPF als Frontend ist es aber deutlich einfacher.

Hi, mir fallen viele Dinge auf die nicht ganz rund sind an dem Code (aber es ist gut das du den SQL Code nicht von Hand generierst!) * Auf den DataAdapter brauchst du nicht Dispose aufzurufen, das passiert automatisch wenn die Referenz aus dem aktuellen Scope läuft * conn.Close brauchst du nicht aufrufen sofern du die Connection nicht vorher mit Open geöffnet hast. Wenn die Connection im State Closed ist macht der DataAdapter sie automatisch selbst auf und schließt sie auch wieder. * Die ganze Ressourcenbereinigung sollte in einem finally Block geschehen, ideal ist hierfür das using-Schlüsselwort Das sind aber nur Kleinigkeiten, dein Code in der for-Schleife macht keinen Sinn weil die neue DataRow bei jedem Durchlauf wieder überschrieben wird. Willst du die neue Row in das Dataset einfügen dann musst du noch die Add Methode des Datasets aufrufen. Deine Frage hast du schon selbst beantwortet. Wenn du in einer Schleife die Collection selbst ändern willst ist eine foreach Schleife nicht geeignet.

Hehe...das mit der Doku hab ich mir auch gedacht.

Hast du noch eine konkrete Frage oder möchtest du dich lieber erstmal mit den Grundlagen beschäftigen?

Vermutlich gehst du mit einem anderen User auf den Server oder hast eine andere Datenbank im Connection-String, dann stimmen die Schema-Informationen nicht mehr. Zudem (ich habe da durchaus missionarische Ansprüche) ist es eine schlechte Vorgehensweise das SQL Command auf diese Weise in den Code zu kneten, das wird irgendwann unwartbar. Besser ist es so ,funktioniert unter VB.NET genau so.