vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Schützen Sie Ihre Software vor Software-Piraterie - mit sevLock 1.0 DLL!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2025
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Fragen & Antworten rund um sev-Komponenten
Re: Access-Absturz durch sevMonthView und sevEingabe 
Autor: Mr. DX
Datum: 05.12.08 12:52

Das mache ich auch so. Ich habe eine Entwicklungs-MDB. In dieser sind alle Komponenten, an denen ich arbeite i.d.R. in mehreren Versionen. Ist ein neues Feature der Anwendung fertig, werden die getesteten Komponenten in die "Kunden-MDB" importiert. Hier werden alle Verweise neu gesetzt, die MDB in eine MDE umgewandelt und dann zusammen mit allen notwendigen Dateien(Runtime-Komp., OCX, DLL usw.) in ein Setup verpackt, das die Kunden dann installieren können. Es gab auch keine Probleme bisher.

Es handelt sich um eine sehr große ERP/CAQ/CRM/PIM-Anwendung für Mittelständler, die im Frontend hunderte von Forms und Module enthält. Ich brauche diese "saubere" MDB, in der nur fertige und getestete Forms importiert werden. Da ich parallel an mehreren Features arbeite, sind in der Entwicklungs-MDB auch viele noch nicht fertige Forms, die in der "Kunden-MDB" nichts zu suchen haben. Wegen der hohen Komplexität ist diese Trennung umbedingt notwendig, weil man ansonsten den Überblick verliert.

Das ich die Verweise in der "Kunden-MDB" neu setzen muß, das stört mich nicht. Das muß ja auch unbedingt gemacht werden. Aber ein Steuerelement bei jedem Kopieren oder Importieren zu deregistrieren und den Verweis zu entfernen um es nachher wieder zu registrieren, das ist schon nervig.

Ich hatte gehofft, daß jemand im Forum schon dieses Problem hatte und eine Lösung gefunden hat. Da dies nicht der Fall ist, habe ich mich selber damit beschäftigt und immerhin diese, wenn auch aufwendige Lösung gefunden. Inzwischen habe ich für das Kopieren sogar eine Lösung gefunden, die ohne jeden Aufwand funktioniert. Kopiert man ein Formular, das sevEingabe enthält, in der Datenbankansicht und fügt es unter einem anderen Namen ein, stürzt Access ab. Öffnet man aber das Formular und speichert es unter einem anderen Namen, funktioniert es problemlos ohne das man sevEingabe deregistrieren und den Verweis darauf entfernen muß. Also muß ich dies nur noch beim Importieren machen. Immerhin eine Erleichterung.

Wie Du sagst, sind die Möglichkeiten in Access bzgl. externer Steuerelementen in Vergleich zu VB oder C ziemlich begrenzt. Man kann lediglich registrieren und Verweise setzen. Ich schätze aber Access als kostengünstiges RAD-Tool mit einer für eine begrenzte Benutzeranzahl performanten Datenbank.

Besten Dank für Dein Interesse an meinem Problem!
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
Access-Absturz durch sevMonthView und sevEingabe1.019Mr. DX03.12.08 15:13
Re: Access-Absturz durch sevMonthView und sevEingabe660ModeratorDieter03.12.08 15:16
Re: Access-Absturz durch sevMonthView und sevEingabe683Mr. DX03.12.08 15:28
Re: Access-Absturz durch sevMonthView und sevEingabe678rsvisionmaster03.12.08 16:04
Re: Access-Absturz durch sevMonthView und sevEingabe641Mr. DX03.12.08 16:59
Re: Access-Absturz durch sevMonthView und sevEingabe644rsvisionmaster03.12.08 17:31
Re: Access-Absturz durch sevMonthView und sevEingabe734Mr. DX03.12.08 18:05
Re: Access-Absturz durch sevMonthView und sevEingabe608Mr. DX04.12.08 23:09
Re: Access-Absturz durch sevMonthView und sevEingabe627rsvisionmaster05.12.08 08:55
Re: Access-Absturz durch sevMonthView und sevEingabe685Mr. DX05.12.08 12:52

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2025 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel