informatikerin86 Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Guten Morgen, mein VB.net-Projekt ist nun entgültig fertig. Alles läuft wie geplant und einiges sogar noch etwas besser Nun zu meiner Frage. Da sich meine Anwendung in den letzten Wochen zig mal am Tag verändert hat und trotzdem damit schon gearbeitet werden sollte habe ich einfach den Release-Ordner meiner Anwendung kopiert und den Benutzer auf dem Server zur Verfügung gestellt. Die Benutzer öffnen die exe-Datei über ein Verknüpfung auf dem Desktop. So konnte ich, wenn keiner gerade aktiv ist, das Release tauschen ohne das jemand etwas bei sich ändern musste. Ist das eine korrekte Vorgehensweise? Nächstes Jahr werden weitere kleinere Änderungen folgen (allerdings nicht mehr durch mich), kann ich das System so weitergeben? Manchmal arbeitet mein Programm wahnsinnig langsam. Ich schiebe es dann immer auf das Netzwerk und die Datenbank die darüber abgefragt wird. Oder kann es daran liegen das alle dieselbe exe-Datei bei sich öffnen und darin arbeiten? Wäre es besser sich jedes mal die Arbeit zu machen und die Anwendung richtig bei den Clients zu installieren? Kennt sich jemand in diesem Gebiet aus? Viele Grüße Informatikerin Zitieren
VaNaTiC Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Das Ablegen einer Anwendung auf einem irgendwie gearteten Netzspeicher ist eine absolut gültige wenn auch etwas pragmatische Realisierung von einer Updatefähigkeit. Ich mach das meistens so, dass ich beim Starten ein Update über einen Webserver mach, der mir ein XML-Dateiliste mit Versionsinformationen liefert, die ich dann mit den lokalen Dateien (Version,Hash,...) prüfe und ggf. update. Ein Trick ist bei Windows z.Bsp., dass man die aktuell gestartete EXE-Datei "renamed" (nicht moved) und dann kann man die neue problemlos speichern. Beim Starten prüft man dann nur noch ob die alte BAK-EXE da ist und löscht sie wenn man das will, ich heb sie immer auf. Das Verteilen einer komplexeren Anwendung ist eine halbe Wissenschaft. Stichworte sind hier beispielsweise: 3-tier, Frontend, Backend, Business Logik, ... Deinen Flaschenhals kann ich leider ohne genauere Angaben über das, was die User in Deiner Anwendung tun und wie die User netztechnisch angebunden sind und über ein bissl Anwendungsinternas nix sagen. Hast Du eine technische Doku, die Du notfalls per E-Mail oder hier zeigen kannst? Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 Hallo, da dies meine erste Anwendung war die ich ohne gigantische Programmierkenntnisse und völlig auf mich gestellt programmiert habe kenne ich mich leider auch in der Dokumentation nicht wirklich aus. Es gibt eine Doku, sie hat 80 Seiten und versucht die Anwendung zu erklären und zu beschreiben wie man sie ändern kann. Ich kann dir gerne was über die Anwendung erzählen. Mit der Anwendung arbeiten momentan etwa 20 Personen(kreise) 12 in der Produktion. Dort wie die Anwendung gestartet, ein Passwortabgleich erfolgt über einen Txt-Datei nicht über Access. Danach wird eine Tabelle aus Access abgefragt. Daraufhin findet keine Interaktion mehr mit Access statt. Access ist nicht in Frontend und Backend aufgeteilt, ich kenne mich nicht besonders auf allerdings gibt es bei mir keine Formulare und keine Berichte, daher denke ich das dies auch nicht sinnvoll wäre soweit ich mich informiert habe. Die anderen 8 Benuter loggen sich ein und laden mehrfach Tabellen aus Access. Alles was Access kann soll in der Anwendung abgebildet werden. Tabellen abfragen, neue Datensätze erstellen, Datensätze verändern, löschen. Access 2003 hat 4KB Speicher, die Anfragen sollten relativ kurz ausfallen und daher denke ich das hier das Problem nicht liegen sollte. Besonders da momentan noch nie mehr als 3 Personen wirklich richtig mit der Anwendung gleichzeitig gearbeitet haben. Ich habe meine Tabellen auf drei DataSets aufgeteilt. Für die verschiedenen Aktionen werden nur genau die Spalten der Tabellen gelesen die auch benötigt werden. Ich weiß nicht ob man damit was anfangen kann... soll ich noch was anderes beschreiben? Mein Rechner in der IT hat natürlich mehr Speicher als die anderen, das sind auch die die sich über die langen Wartezeiten beschweren. Ich denke das es auch daran liegen könnte, da wir strikte Vorgaben haben ist dies allerdings nicht zu ändern. Die Frage ist: KANN es an der exe-Datei liegen die mehrere benutzen? Und ist eine Installation besser oder einfach nur das Benutzen des Releases?! PS: Wie sieht denn eine technische Doku aus? Zitieren
K9s Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 (bearbeitet) Ich verwende die ClickOnce-Funktionalität, da diese im VisualStudio zur Verfügung steht. Darüber kannst du zum Beispiel die Updates, zentral über einen Webserver zu Verfügung stellen. ClickOnce Deployment http://openbook.galileocomputing.de/visual_csharp/visual_csharp_31_002.htm#mjebbc6056ee88fbe4806c25fb8d852094 Darum habe ich mich dafür entschieden: - ich muss die Software nicht auf jedem PC installieren, sondern nur an einer Stelle bereitstellen - Der Client prüft immer, ob er mit der aktuellst Version abreitet und wenn nicht installiert er diese automatisch - darüber hat man eine minimal Versionierung. Ich verwende VS2008 und C# 2008 Express. Bearbeitet 16. Dezember 2009 von K9s Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 Danke für den Tipp. Das klingt gut, wenn ich dazu einen passenden Webserver finde wäre das eine tolle Idee!! Zitieren
K9s Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Es muss nicht unbedingt ein Webserver sein, du kannst auch einen Fileshare verwenden. Zitieren
VaNaTiC Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Die Frage ist: KANN es an der exe-Datei liegen die mehrere benutzen? Nein, das kann ich mir nicht vorstellen. Da die EXE über das Netzwerk zum Ausführen ohnehin in den Speicher des Anwenderrechners üertragen wird. Wie äußert sich das "langsam"? Startet die Anwendung langsam und ist dann schnell? Gehen Abfragen langsam? Wenn ja, sind das die Selects oder die Inserts/Updates? Wo liegt Deine Access-DB als Datei? Geht es bei Dir schneller mit derselben Konfig (Produktiv-DB, keine Test-DB)? Geht es bei den Anwendern schneller, wenn die Anwendung und DB (also alles) direkt lokal gestaret wird? Bei Access gibt es verschiedene Cursor-Modie: Client-seitig, Server-seitig, ... Das solltest Du mal kontrollieren, genauso wie die Puffergröße. Meist wird das im (JET/ODBC/...-)Treiber eingestellt. PS: Wie sieht denn eine technische Doku aus? Unterschiedlich! Aus Softwareentwicklersicht eher mit UML, Programmablaufpläne DIN 66001 oder Struktogramme DIN 66261, Quellcode-Dokumentationen, Schemapläne, ... Aus Verwaltungssicht eher nach DIN 66230, oder banal als Pflichten- und Lastenheft. ... Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 Danke, es beruhigt mich das es nicht an der exe liegt. Das konnte ich mir zwar nicht vorstellen, aber man weiß ja nie Langsam ist die Anwendung beim Starten und beim benutzen. Wenn sie langsam startet kann man davon ausgehen das sie alles langsam macht. Die Access-DB liegt auch auf dem Server, genau dort wo auch die exe-Datei liegt. Es gibt keine Test-DB, ich arbeite direkt in der echten Datenbank. (eine Sicherung ist vorhanden) Hm.. die Anwendung und DB lokal starten... dazu müsste ich schnell in denn Quellcode um den Pfad der DB zu ändern. Das werde ich mal ausprobieren!! Bei Access gibt es verschiedene Cursor-Modie: Client-seitig, Server-seitig, ... Das solltest Du mal kontrollieren, genauso wie die Puffergröße. Das verstehe ich nicht, kannst du mir sagen wo ich diese Einstellungen finde?? Und danke für den Hinweis zur Dokumentation. Ich arbeite ab Januar als richtige Softwareentwicklerin, da ist es sicher von Vorteil wenn ich mir das schon mal anschaue!! Zitieren
VaNaTiC Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Langsam ist die Anwendung beim Starten und beim benutzen. Wenn sie langsam startet kann man davon ausgehen das sie alles langsam macht. Habe ich das im Umkehrschluß richtig verstanden, dass es also nicht immer auf den Anwenderrechnern langsam ist? Die Access-DB liegt auch auf dem Server, genau dort wo auch die exe-Datei liegt. Hmm, dafür ist Access-DB nicht so dolle ausgelegt. Hm.. die Anwendung und DB lokal starten... dazu müsste ich schnell in denn Quellcode um den Pfad der DB zu ändern. Gewöhn Dir sowas lieber nicht zu dolle an. Besser macht man solche Einstellungen in eine INI-Datei. Ich bin gespannt auf das Ergebnis, wenn die DB lokal ist. Das verstehe ich nicht, kannst du mir sagen wo ich diese Einstellungen finde?? Für ADO gibt es hier eine Erklärung: Using Cursors with ADO Und danke für den Hinweis zur Dokumentation. Ich arbeite ab Januar als richtige Softwareentwicklerin, da ist es sicher von Vorteil wenn ich mir das schon mal anschaue!! Ohja Kollegin, zum Entwicklungsprozess einer Software gehören zig Dinge, mal mehr mal weniger ausgeprägt. Programmieren an sich ist nur der geile Teil dabei :-D Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 Habe ich das im Umkehrschluß richtig verstanden, dass es also nicht immer auf den Anwenderrechnern langsam ist? Ja, das habe ich damit gemeint. Also es läuft nie so das man denkt: wow. Aber manchmal dauert eine Meldung die Informationen aus 15 Tabellen zieht ein paar Sekunden und dann gehts 2 Minuten bis sie erscheint. Hmm, dafür ist Access-DB nicht so dolle ausgelegt. Ich kann sie aber auch sonst nirgends hinlegen, sie muss schon auf dem Server bleiben! Gewöhn Dir sowas lieber nicht zu dolle an. Besser macht man solche Einstellungen in eine INI-Datei. Ich habe den Pfad nicht direkt im Quellcode, sondern als Einstellung in der MyProject-Datei die Visual Studio anlegt. Somit ist das eine kurze schnelle Änderung, ähnlich wie eine ini-Datei. Falls es sich dabei nicht sogar um so etwas, grafisch aufbereitet, handelt. Ich bin gespannt auf das Ergebnis, wenn die DB lokal ist. Ich bemerke keine großen Unterschiede was die Zeiten angeht. Vielleicht ist das auch gut, dann liegt es nicht am Netzwerk! Blöderweise liegt es dann an Access oder meinem Code... Codeänderungen in 2 Tagen sind nicht drin. Kann ich dann überhaupt noch was machen? Für ADO gibt es hier eine Erklärung: Using Cursors with ADO Der Link hilft mir leider nichts da ich nicht mit dem Recordset arbeite. Ohja Kollegin, zum Entwicklungsprozess einer Software gehören zig Dinge, mal mehr mal weniger ausgeprägt. Programmieren an sich ist nur der geile Teil dabei :-D 6 Monate programmieren ohne Regeln... war ja klar das das irgendwann ein Ende haben muss. Nun widme ich mich dem ernst des Lebens das mir in meinem Studium immer versprochen wurde Zitieren
VaNaTiC Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 In zwei Tagen wirst Du keine großen Sprünge mehr machen. Aus 15 Tabellen laden? Wieviele Datensätze haben die denn? Tritt das Problem auch auf, wenn immer nur ein User die Anwendung benutzt? Sind bei großen Tabellen die Datenbankfelder, die im where oder in joins sind als Sekundär-Indezies angelegt? Zitieren
athlet1 Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Ja, das habe ich damit gemeint. Also es läuft nie so das man denkt: wow. Aber manchmal dauert eine Meldung die Informationen aus 15 Tabellen zieht ein paar Sekunden und dann gehts 2 Minuten bis sie erscheint. Ich bemerke keine großen Unterschiede was die Zeiten angeht. Vielleicht ist das auch gut, dann liegt es nicht am Netzwerk! Blöderweise liegt es dann an Access oder meinem Code... Codeänderungen in 2 Tagen sind nicht drin. Kann ich dann überhaupt noch was machen? Arbeitest du mit Indizes? Sind die Queryparameter (von Typ und Anzahl her, nicht der Inhalt) dynamisch oder eigentlich immer die selben? Gehen die Queryparameter auf die Indizes? Erlaubst du Textsuchen? Und so weiter und so weiter. Die Antwort auf die Fragen würde helfen, ob bei dir nochwas geht. Die Datenbank versucht immer die beste Strategie zu finden, mit der die gestellte Aufgabe (Query) am besten zu lösen ist. Je nach Inhalt der Abfrage ist der Lösungsweg ein anderer. Dies würde erklären, warum es mal schnell und mal lahm geht. Informationen aus 15 Tabellen in einer Query!? Die ganzen Joins machen dein System so oder so lahm. Ich habe den Pfad nicht direkt im Quellcode, sondern als Einstellung in der MyProject-Datei die Visual Studio anlegt. Somit ist das eine kurze schnelle Änderung, ähnlich wie eine ini-Datei. Falls es sich dabei nicht sogar um so etwas, grafisch aufbereitet, handelt. Was der Kollege meinte ist wohl eher, dass man die Einstellung ohne zuhilfenahme des Visual Studios ändern kann. In .NET muss man für sowas auch nicht mehr mit ini-Dateien umgehen, dafür gibt es die app.config (u.a. es gibt immer mehrere Möglichkeiten). 6 Monate programmieren ohne Regeln... war ja klar das das irgendwann ein Ende haben muss. Wenn man die schlechten Seiten gesehen hat, erscheinen einem die neuen Dinge/Vorgehensweisen wie das Allheilmittel. Und das ist nur der Anfang, dieses Spiel geht immer weiter:) Und zu deiner eigentlichen Frage: Ergeben sich die Updates aus Änderungen an der Businesslogik oder der GUI? Gruß Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 So, dann versuche ich mal die Fragen alle zu beantworten! Momentan haben die Tabellen in der Access-Datenbank zwischen 0 und 40 Datensätze. Das soll natürlich noch erheblich mehr werden in nächster Zeit. Ich arbeit nicht mit Indezies. Ehrlich gesagt weiß ich bis ich es gleich google nicht was das ist. Das Problem tritt auch auf wenn nur ein Benutzer die Anwendung benutzt. Ich habe keine Tabellen-Joins. Es gibt keine Verknüpfungen zwischen den Tabellen. Es werden 15 Tabellen geladen, daraus allerdings immer nur den Primary Key und den Status des Datensatzes. Die Informationen werden nacheinander direkt aus der DataTable geladen. Queryparameter? Ich arbeite mit einem typisierten DataSet das mehrere DataTables enthält. Die Einstellungen darin sind immer dieselben... Textsuchen erlaube ich nicht. Die Updates ergeben sich aus Änderungen an der Businesslogik und der GUI. Die nächsten Monate wird es sich auf die GUI beschränken, aber Logik-Änderungen danach sind auf jeden Fall vorgesehen. Das müsste alles gewesen sein... so ein Durcheinander. Jetzt werde ich erstmal eure Bergiffe googeln und mich schlauer machen! Zitieren
TDM Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 (bearbeitet) Was der Kollege meinte ist wohl eher, dass man die Einstellung ohne zuhilfenahme des Visual Studios ändern kann. In .NET muss man für sowas auch nicht mehr mit ini-Dateien umgehen, dafür gibt es die app.config (u.a. es gibt immer mehrere Möglichkeiten). Wird die app.config nicht auch zu einer DLL? Ich würd da lieber eine config.xml oder so schreiben und dynamisch laden lassen, damit man nicht immer neu kompilieren muss. :floet: [Editerle] Ich arbeit nicht mit Indezies. Ehrlich gesagt weiß ich bis ich es gleich google nicht was das ist. [...] Es werden 15 Tabellen geladen, daraus allerdings immer nur den Primary Key und den Status des Datensatzes. PKs sind u.a. indiziert, also doch. Bearbeitet 16. Dezember 2009 von TDM Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 So, da ich nun gelernt habe das der Primary Key ein Indizie ist, nun nochmal meine korrigierte Antwort: Ja, ich benutze Indizies. Allerdings benutze ich keine Sekundar-Indizies. Zitieren
VaNaTiC Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Bei 40 Datensätzen ist das eh unerheblich, als ich fragte ob Du auf die Felder in den where- und join-Klauseln Sekundärindizies hast. Ich könnte Dir empfehlen mit einem Profiler mal das Ganze zu analysieren. Oder ein Selfmade-profiler ist zum Beispiel eigener Time-Counter, der die Laufzeitdifferenz zwischen bestimmten Arbeitsschritten misst, summiert und zyklisch oder am Ende loggt. Damit findet man oft auf pragmatischem Weg auch ohne Profiler den Flaschenhals. Aber in 2 Tagen ist das eh Wurst, also lass es Zitieren
informatikerin86 Geschrieben 16. Dezember 2009 Autor Geschrieben 16. Dezember 2009 Wunderbare Antwort *g* also lasse ich das und sage es liegt am Netzwerk..... :floet: Zitieren
athlet1 Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 Wird die app.config nicht auch zu einer DLL? Ich würd da lieber eine config.xml oder so schreiben und dynamisch laden lassen, damit man nicht immer neu kompilieren muss. :floet: Also eine app.config ist genau das, was du mit config.xml beschreibst;), also keine DLL. Zitieren
TDM Geschrieben 16. Dezember 2009 Geschrieben 16. Dezember 2009 hmm ok, hab nochmal alle Debugordner durchforstet, wirklich überall *.xml Hätte schwören können ich hab mal eine *.exe.config.dll gesehen. Naja egal... Zitieren
athlet1 Geschrieben 17. Dezember 2009 Geschrieben 17. Dezember 2009 hmm ok, hab nochmal alle Debugordner durchforstet, wirklich überall *.xml Hätte schwören können ich hab mal eine *.exe.config.dll gesehen. Naja egal... Die Application Configuration Files sind nicht nach dem Schema *.xml abgespeichert. Du liegst mit deiner Vermutung so etwas gesehen zu haben schon nah dran, aber richtig sieht es so aus: *.exe.config oder *.dll.config Die app.config im Projekt wird beim kompilieren zu <AssemblyName>.<OutputType>.config. Als Beispiel: explorer.exe.config oder eben explorer.dll.config Grüße Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.