.NETter

Hallo, ich habe mich jetzt nicht intensivst mit der Aufgabenstellung, sondern nur etwas mit der Planung der DB beschäftigt. Ich habe das ERM so angepasst, dass die DB nur in einer Filiale läuft, also nicht in einem Filialnetz. So werden die Filialdaten in einer Tabelle gehalten, aber nicht von anderen Tabellen referenziert. Ansonsten müsste man die FilialID noch in weiteren Bereichen unterbringen. Unter anderem habe ich zur einer Lieferung auch eine Bestellung eingefügt. Das kann man aber auch wieder raus nehmen falls es überflüssig ist. Hier mal mein ERM: Bei Fragen einfach nochmal schreiben! Gruß, Thomas

Hallo, der Test lief bei mir auch auf XP und Vista einwandfrei. Gruß, Thomas

Hallo! Habe das gerade mal getestet und das Datum des letzten Zugriffs wird korrekt ausgegeben. Auch nach dem Zugriff durch meine Anwendung wird das Datum des letzten Zugriffs auf die Datei in keiner Weise geändert. Hier mal der Code: public static void Main() { FileInfo fi = new FileInfo(@"c:\XMLFile.xml"); Console.WriteLine(fi.LastAccessTime.ToString()); Console.ReadKey(); } Gruß, Thomas

Hallo, Du kannst den System.Timer nutzen. Code aus der Doku: Imports System Imports System.Timers Public Class Timer1 Private Shared aTimer As System.Timers.Timer Public Shared Sub Main() ' Normally, the timer is declared at the class level, ' so that it stays in scope as long as it is needed. ' If the timer is declared in a long-running method, ' KeepAlive must be used to prevent the JIT compiler ' from allowing aggressive garbage collection to occur ' before the method ends. (See end of method.) 'Dim aTimer As System.Timers.Timer ' Create a timer with a ten second interval. aTimer = New System.Timers.Timer(10000) ' Hook up the Elapsed event for the timer. AddHandler aTimer.Elapsed, AddressOf OnTimedEvent ' Set the Interval to 2 seconds (2000 milliseconds). aTimer.Interval = 2000 aTimer.Enabled = True Console.WriteLine("Press the Enter key to exit the program.") Console.ReadLine() ' If the timer is declared in a long-running method, use ' KeepAlive to prevent garbage collection from occurring ' before the method ends. 'GC.KeepAlive(aTimer) End Sub ' Specify what you want to happen when the Elapsed event is ' raised. Private Shared Sub OnTimedEvent(source As Object, e As ElapsedEventArgs) Console.WriteLine("The Elapsed event was raised at {0}", e.SignalTime) End Sub End Class Gruß, Thomas

Hallo, bei Access 2003 kann ich Dir das garnicht beantworten :-( Arbeitet ihr dort nur mit Access? Oder gibt es hier noch einen SQL Server? Hintergrund der Frage ist ob Du hier nicht ein DTSX-Paket basteln kannst, was die Sache natürlich vereinfachen würde. Der reine Import in Access bietet (meines Wissens nach) keine Überprüfung der Datensätze auf festgelegte Einschränkungen. Mit einem DTSX-Paket könnte man den Import und die Überprüfung jedes einzelnen Datensatzes natürlich prima erledigen. Ebenso könnte man das Mapping bestens integrieren. Je mehr Besonderheiten beim Import entstehen (kein leeres Datum etc.) desto eher würde ich doch zu einer eigenen Anwendung oder besser einem DTSX-Paket tendieren. Mögen mich alle VBA-Programmierer jetzt ruhig nieder machen, aber ich drücke mich davor wo es nur geht :-) Damit könnte man bestimmt auch viele Dinge erledigen, aber da kann ich Dir nicht weiter helfen, sorry. Viele Grüße, Thomas

Hallo, leider kam ich garnicht früher zum Schreiben. Ich würde hier erstmal differenzieren welche Attribute Du hier wirklich benötigst. Davon ist natürlich abhängig wie groß der Datenbestand sein wird. In der Express Edition vom SQL Server stehen Dir 4 GB für Daten zur Verfügung. Ich denke, dass ist für die Ablage von reinen Attributen in Textform selbst dann ausreichend wenn Du wirklich alle Attribute speichern würdest. Theoretisch wären das 4.294.967.296 Zeichen die Dir zur Verfügung stehen und pro User (bei 15.000) eben ca. 286.300 Zeichen. Also "FEEL FREE" :-) Gruß, Thomas

Hallo, AD-Abfragen dauern je nach Größe des AD´s immer recht lang. Du fragst hier auch immer alle im AD vorhandenen User(?) ab. Da lässt sich so weiter auch nichts optimieren. Aber hier ein anderer Vorschlag der für Dein Vorhaben sehr helfen könnte. Schreibe Dir eine Anwenung (oder Dienst) der in einem akzeptablen Intervall alle AD-Einträge die du benötigst in eine Datenbank schreibt bzw. aktualisiert. Ob dieser nun 10 Minuten benötigt ist für Deine anwendung dann erstmal uninteressant. Deine jetzige Anwendung sollte dann auf den Datenbestand der DB zugreifen und nicht mehr direkt auf das AD. Dadurch hast du eine enorme Performancesteigerung und die AD-Daten ändern sich ja nicht sooo häufig denke ich. Ich habe mit dieser Vorgehensweise ebenfalls eine Anwendung optimiert die seit dem extremst schnell ist und das hat den Kunden sehr gefreut. Hierfür genügt in jedem Fall ein kostenloser Datenbankserver wie z.B. SQL Server 2008 Express Edition. Hoffe das hilft Dir etwas weiter! Viele Grüße, Thomas

Hallo, hierfür benötigst u aber kein Webpart, es genügt eine simple Anwendungsseite welche (ist ja ASP .Net) eine Codebehinddatei nutzt und von dieser erbt. Diese Seite kannst Du in einem Feature per Featuredeployment (STSADM.exe) zum SP bringen. Im Codebehind der Seite kannst Du den Namespace von SP nutzen (mit einem Verweis auf die SharePoint.dll und einer using-Direktive) Dinge wie SPSite, SPList und auch SPListItem sind somit nutzbar. z.B. LoadEvent SPWeb site = this.Web; foreach(SPList l in site.Lists) { //Itteration der Listen foreach(SPListItem li in l.Items) { //Itteration der Listeneinträge } } Gruß, Thomas

Hallo, Listen werden nicht Farm-weit deployed, sondern auf Site- oder Webebene... Wenn Du alle Webapplications, Sitecollections, und deren Webs itterieren möchtest, kannst Du das natürlich tun. Vorausgesetzt du hast in jedem dieser Bereiche auch Rechte. Wo soll Dein Webpart denn laufen? Wie und wo willst Du Dein Webpart veröffentlichen? Was willst Du denn überhaupt sehen? ListTemplates oder ListInstances usw. Wie gesagt Grundlagen sind alles! Gruß, Thomas

Hallo! Alo ich kann Dir dafür keine Patentlösung nennen. Aber ich hatte einen ähnlichen "Absturz" einer Anwendung nachdem ich eine Tabelle im DataSet kopiert habe, also Strg+C und Strg+V. nachdem ich diese Tabelle wieder gelöscht hatte war das Problem verschwunden. Viele Grüße, Thomas

Geduld und Beharrlichkeit zahlen sich immer aus! Kein Problem, gern geschehen! Gruß, Thomas

Ja, Access 2007 kann kann die Spalten anhand ihrer Namen problemlos mappen. Ich würde die Definition deiner CSV-Datei schriftlich dokumentieren (also als verbindliches Interface) und an die verantwortlichen Leute weitergeben. Da man als AE nicht immer ganz oben in der Nahrungskette steht werden Änderungen natürlich irgendwann doch stattfinden. Aber durch die Bekanntgabe dieser Schnittstellendefinition wissen die Verantwortlichen zumindest Bescheid und haben die Chance (vielleicht sogar Pflicht) Dich über Änderungen zu informieren. Falls der Informationsfluss dann nicht greifen sollte kannst Du zumindest auf ein Dokument hinweisen, was sie ja dann zumindest gelesen haben sollten. So wärst Du schon mal auf der sicheren Seite was die Verantwortung vor Deinem Vorgesetzten angeht. Ändern kannst Du den Import dann ja immernoch. Viele Grüße, Thomas

Hallo, da ich gerade selbst Features für MOSS entwickel, kann ich Dir nur empfehlen ein Buch (oder mehrere) zu kaufen. Die Entwicklung im SharePoint-Bereich gestaltet sich im Gegensatz zur reinen .Net Entwicklung sehr ungewohnt. Du solltest hier auch erstmal ganz kleine Brötchen backen und nicht gleich mit WebParts beginnen. In MOSS bzw. WSS werden Features entwickelt. Visual Studio ist hier auch nicht wirklich eine große Hilfe, da großenteils nur XML-ähnliche Definitionsdateien geschrieben werden. Verzeichnisstrukturen müssen in VS nachgebildet werden etc. Auch das Deployment ist nicht Visual Studio-LIKE. Hier werden Anwendungen des MOSS/WSS genutzt (STSADM.exe). Wirklicher .Net Code kommt dann erst z.B. in einem FeatureReceiver der eben Aktionen für Dein Feature behandelt. Da dies alles etwas komplexer ist würde ich dort auf jeden Fall ein Buch verwenden, auch um die Hintergründe (Webapplication, Sitecollection, Rootweb, Website etc.) von SharePoint zu verstehen, denn dies ist absolutes MUSS für die Entwicklung. Aber nicht entmutigen lassen! Das ist auch alles kein Hexenwerk nur eben sehr gewöhnungbedürftig. Meine persönliche Buchempfehlung wäre: Windows SharePoint Services 3.0 Programmierung (Microsoft Press) Es ist für den Anfang gut geeignet und gibt einem erstmal eine Übersicht über SharePoint-Techniken. Es ist mit vielen Beispielen und How to´s ausgestattet. Mir hat es am anfang sehr geholfen! Viele Grüße, Thomas

Hallo, in Deiner ParentForm gibt es keine RichtextBox mehr. In den ClientForms bezieht sich "this" immer auf sich selbst, also auf die eigene Form. Jedes Objekt vom Typ Form2 kann seine eigene RichtextBox mit this.richtextBox1 ändern. In der ParentForm darf es keinen Verweis auf irgendeine RichtextBox geben. Die Objekte vom Typ Form2(ClientForm) ändern ihre Eigenschaften (Text in der Box) an sich selbst. Die ParentForm sagt ihnen nur, dass sie es tun sollen. Also raus mit RichtextBox in der ParentForm Gruß, Thomas

Hallo, im Kapitel 8 steht wirklich Schritt für Schritt was getan werden muss. Auch Wichtig "Treiber Installation". "Geht nicht" ist eine magere Beschreibung. Was passiert? Welche Fehlermeldung wird ausgegeben? Gruß, Thomas

Hallo! Das Interface war jetzt garnicht spezifisch auf Softwareentwicklung bezogen, sondern einfach als Definition auf einen gemeinsamen Nenner. Es besteht immer die Möglichkeit das zu importierende Daten sich ändern können. In diesem speziellen Fall mit SAP könnte dies zum Beispiel eine View auf SAP-Seite sein aus der die Daten für die CSV-Datei abgezogen werden. So hättest Du immer eine Art Garantie für passende Datenstrukturen. Was Du natürlich auch tun kannst, ist die Daten garnicht aus der CSV-Datei zu beziehen sondern direkt in SAP abzufragen. Es gibt hierfür Datenprovider für ADO.Net: SAP Library - ADO.NET Interface Ich denke solange Du aus einer CSV-Datei Daten abziehen wirst, wird immer das Risiko bestehen eines Tages vor die Wand zu laufen. Wie sieht es mit den Spaltennamen der CSV-Datei aus? Sind die enthalten? Vielleicht kannst Du zumindest so etwas Kontrolle in die Sache bringen indem Du nur Daten aus bekannte Spaltennamen importierst. (Eigene anwendung schreiben). Gruß, Thomas

Hallo, die Vorgehensweise ist die gleiche, ob nun OleDB oder ODBC. Aber ich denke Du solltest Dir wirklich einmal allgemeine Grundlagen aneignen. Hier nochmal der bereits empfohlene Link: Galileo Gruß, Thomas

Ich hoffe dass wir nun alle Klarheiten beseitigt haben Nein, nein! Wenn noch Du noch etwas Hilfe benötigst einfach schreiben! Gruß, Thomas

Hallo, Guybrush Threepwood hat da völlig recht. Ich habe das mal etwas zusammen gefasst was dafür zu tun ist. Du erstellst eine Variable vom Typ Deiner ChildForm(Form2) in deinem MDI-Container(Form1) private Form2 currentForm = null; In der ChildForm (Form2) erstellst Du eine öffentliche Methode die einen String entgegen nimmt und die eigene Textbox mit Text füllt. public void SetMyTextbox(String Eintrag) { this.textBox1.Text = Eintrag; } In Form1 benutzt Du eine Schaltfläche(hier z.B. auf einer eine Menuebar) um den Text in einer Unterform zu setzen. Die Variable currentForm(vom Typ Form2) in der Form1 speichert beim Aufruf der Methode zum setzen des Textes, die momentan aktive Form. Dann rufst Du an der Variable die Methode "SetMyTextox" auf. So wird der Text immer nur in der gerade aktiven Form gesetzt. private void seToolStripMenuItem_Click(object sender, EventArgs e) { if (this.ActiveMdiChild != null) { currentForm = (Form2)this.ActiveMdiChild; currentForm.SetMyTextbox("Hier ist der Eintrag!"); } } Ich habe hier keine Fehlerbehandlung eingebaut. Falls Du ChildForms hast die nicht vom Typ Form2 sind wird dies Exceptions werfen. Gruß, Thomas

Provider=MySQLProv;Data Source=Dein Host-/Datenbankname;User Id=DeinBenutzername;Password=DeinPasswort Connectionstrings kannst Du auch hier nachschlagen: connectionstrings.de

Hallo, die Fragezeichen sind Platzhalter für Parameter. Also bleiben die Fragezeichen stehen. Für jeden Wert den Du in VALUES() übergeben willst stellst Du ein Fragezeichen ein. Beispiel: INSERT INTO tabelle1 (vorname, nachname) VALUES (?, ?) In dieser Reihenfolge wie du die Werte im SQL-Statement benötigst fügst du die OleDB-Parameter dem Command hinzu. Dim paramVorname As New OleDbParameter("@vorname", OleDbType.VarChar, 100) Dim paramNachname As New OleDbParameter("@nachname", OleDbType.VarChar, 100) 'Hinzufügen der Parameter zum Command ([COLOR="Red"]Hier ist die Reihenfolge WICHTIG![/COLOR]) cmd.Parameters.Add(paramVorname).Value = "Bill" cmd.Parameters.Add(paramNachname).Value = "Gates" Daher ist die Reihenfolge wichtig. Die Parameter haben im Statement keinen Namen und werden nur der Reihenfolge nach zugewiesen.

Der Beste Dank wäre wenn irgendwann mal kommt "ES FUNKTIONIERT!" Gruß, Thomas

Hallo, ich tippe darauf, dass es an der noch fehlenden Transaktionssicherheit liegt. Ich habe mir mal die Mühe gemacht und den Code von gestern etwas angepasst. Es werden jetzt OleDB-Parameter genutzt. Das Command-Objekt führt das SQL-Statement jetzt in einer Transaktion aus. Das Schreiben in geschützten Speicher... usw. ist eine häufige Fehlermeldung für nicht transaktionssichere Anweisungen. Hier mal der neue Code (Bitte auf die noch zu erstellenden Anpassungen achten!): Private Sub cmdspei_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdspei.Click 'Connection erstellen / Der Connectionstring muss natürlich angepasst werden! Dim con As New OleDb.OleDbConnection("Hier steht Dein Connectionstring") 'Statement als string erstellen (Noch ergänzen! Für jeden Parameter ein Fragezeichen...) Dim sql As String = "INSERT INTO vbtest(Kundenname, Spotname) VALUES (?, ?)" 'Command erstellen und diesem das SQL-Statement zuweisen! Dim cmd As New OleDb.OleDbCommand(sql) 'Parameter erstellen (100 ist hier die Feldgröße also anpassen!) Dim paramKundenname As New OleDbParameter("@kundenname", OleDbType.VarChar, 100) Dim paramSpotname As New OleDbParameter("@spotname", OleDbType.VarChar, 100) 'Hier werden Parameter hinzugefügt was wesentlich sicherer und im SQL-String einfacher zu handhaben ist 'Hinzufügen der Parameter zum Command (Hier ist die Reihenfolge WICHTIG!) cmd.Parameters.Add(paramKundenname).Value = txtkname.Text cmd.Parameters.Add(paramSpotname).Value = txtspname.Text Dim transaction As OleDbTransaction Dim affectedRows As Integer = 0 Try 'Verbindung zur DB öffnen con.Open() transaction = con.BeginTransaction(IsolationLevel.ReadCommitted) cmd.Connection = con cmd.Transaction = transaction 'Command ausführen affectedRows = cmd.ExecuteNonQuery() 'Verbindung wieder schliessen transaction.Commit() con.Close() MessageBox.Show(String.Format("Es wurden {0} Datensätze eingefügt.", affectedRows.ToString())) Catch ex As Exception MsgBox(ex.Message) Finally con.Close() End Try End Sub Gruß, Thomas