Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Warum ist Access so verhaßt?
LastGentleman
myCSharp.de - Member

Avatar #avatar-1696.jpg


Dabei seit:
Beiträge: 1274
Herkunft: Österreich

Themenstarter:

Warum ist Access so verhaßt?

beantworten | zitieren | melden

Hallo zusammen,

immer wieder stoße ich hier im Forum wenn das Thema Access angeschnitten wir auf Ablehnung bis hin zum extremen Haß? Gibt es dafür gründe?
Ich verwende Access täglich und nicht nur als Backend. Ja es stürzt hin und wieder ab, aber man kann ja wunderbare sachen damit machen in einer Geschwindigkeit.
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
private Nachricht | Beiträge des Benutzers
Quadrina
myCSharp.de - Member



Dabei seit:
Beiträge: 20

beantworten | zitieren | melden

Also ich hab nicht so gute Erfahrungen damit. 1. ODBC, was ab einer gewissen Datenmenge einfach das Netz in die Knie zwingt und zu langen Wartezeiten führt
2. das Sperren von ganzen Tabellen oder Datensatzblöcken, was ab einer bestimmten Useranzahl auch unangenehm wird
3. so manche "Microsoft"-typische Macke wie selbständig Änderungen durchführen (ähnlich MS Word ab 150 Seiten....)
4. ich habe keinen Überblick, wie welche Tabellen, Formulare, Abfragen usw zusammenhängen,


Na ich glaub das wars dann erst mal. Übrigens sind 1 bis 4 auch die Gründe, warum ich mich mit C# und MSDE rumärger, an dieser Stelle noch mal an alle Leser: HILFE!! ;-)

Qu.

P.S. an sich bin ich ein eingeschworener MS-Fan, aber manche Sachen...oje
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 10072

beantworten | zitieren | melden

Nun die meisten die darüber negativ schreiben, haben mit Multiuser,
verteilten Anwendungen und grösseren Datenmengen zu tun, und
dafür taugt Access definitiv nicht.

Ansonsten gibt es zu viele Access-Friemler, also Leute die mal eben eine Accessanwendung
zusammenstricken, ohne wirklich Ahnung von SW Entwicklung zu haben, und
deren "Arbeit" müssen einige von uns dann wieder geradebiegen, und
irgendwann hasst man halt, dass Access es solchen Leuten überhaupt erst
ermöglicht hat SW zu schreiben.

Ich kenne auch Access-Anwendungen die gut designed, und wirklich modular
und wartbar sind, aber die sind leider die Ausnahme.

Aber das ist meine persönliche erfahrung mit Access, und in abgewandelter Form
auch mit VB6.
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Zitat
Original von FZelleAnsonsten gibt es zu viele Access-Friemler, also Leute die mal eben eine Accessanwendung
zusammenstricken, ohne wirklich Ahnung von SW Entwicklung zu haben, und
deren "Arbeit" müssen einige von uns dann wieder geradebiegen, und
irgendwann hasst man halt, dass Access es solchen Leuten überhaupt erst
ermöglicht hat SW zu schreiben.
Genau, wobei man in dem Absatz Access auch mit VB ersetzen könnte. Ich weiß nicht wieviel VB-Gefrickel sich da in der Welt herumtreibt, aber bisher standen mir noch bei jedem VB-Code, den ich gesehen habe, die Nackenhaare auf... X(
Zitat
Original von QuadrinaP.S. an sich bin ich ein eingeschworener MS-Fan, aber manche Sachen...oje
Was hat denn Fan-sein mit der Wahl des richtigen Tools für eine bestimmte Aufgabe zu tun?
Jet war vllt vor 10 Jahren eine nette Entwicklung... Wurde aber seitdem nicht wirklich weiterentwicklelt und es gibt einfach keine Nische mehr, indem es besser als seine Konkurrenz wäre. Deshalb ist Jet als DBMS zwangsläufig immer die schlechtere Wahl.

Hier mal ein paar low cost/Open source DBMS, die Jet in der jeweiligen Aufgabe absolut alt aussehen lassen.
Single user/lokal -> firebird embedded, SQL Lite, NexusDB embedded
Mehrbenutzer -> firebird server, nexusDB Server, pgSQL, vllt sogar MSDE/SQLX
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8775
Herkunft: Berlin

beantworten | zitieren | melden

Ich hasse Access nicht, sehe aber nicht, welchen Vorteil das System bietet, so dass ich es heute noch einsetzen wollen würde. Es gibt einfach Moderneres und Besseres.
private Nachricht | Beiträge des Benutzers
Bini
myCSharp.de - Member

Avatar #avatar-1555.jpg


Dabei seit:
Beiträge: 195
Herkunft: der wilde Osten

beantworten | zitieren | melden

Ich kann Access nicht leiden, weil es umständlich ist, "reines" SQL einzugeben. Ich möchte nicht pausenlos von Assistenten geführt werden, die bei meinem speziellen Problem ohnehin nicht ausreichend sind. Meine Standard-Umgebung ist Oracle mit PL/SQL-Developer und was die einfache Bedienbarkeit angeht, ist Access Lichtjahre davon entfernt.
Umwege erhöhen die Ortskenntnis.
private Nachricht | Beiträge des Benutzers
JoKi
myCSharp.de - Member

Avatar #avatar-1587.png


Dabei seit:
Beiträge: 128
Herkunft: Mauritius

beantworten | zitieren | melden

Hallo,
Zitat
Original von LastGentleman
immer wieder stoße ich hier im Forum wenn das Thema Access angeschnitten wir auf Ablehnung bis hin zum extremen Haß? Gibt es dafür gründe?
Ich verwende Access täglich und nicht nur als Backend. Ja es stürzt hin und wieder ab, aber man kann ja wunderbare sachen damit machen in einer Geschwindigkeit.

Naja, Access ist eine Office-ANWENDUNG, keine Entwicklungsumgebung zum Erstellen von Applikationen. Nur sehen das viele Nutzer nicht wirklich ein. Allein die Tatsache, dass man keine EXE kompilieren kann, sollte eigentlich schon DAS KO-Kriterium für einen professionellen Eindruck sein, oder?
Ich persönlich habe nichts gegen Access, aber ehrlich gesagt aber auch nichts für. Warum sollte ich mit dem Fahrrad 300 Kilometer mühsam zurücklegen, wenn ich den Sportwagen (Visual FoxPro) oder die Bahn (SQL Server) nutzen kann?

Meines Erachtens verdankt Access seine Verbreitung ausschliesslich der Tatsache, dass es im Office automatisch drin ist. Und dann wird halt "mal so nebenbei" was mit Datenbanken probiert. Ich kann dir von MDBs erzählen, da bleibt dir sicherlich die Spucke weg...

Ansonsten, bleibt lediglich zu sagen, dass man mit Access garantiert sehr gute Lösungen produzieren kann, außer Frage, aber das kommt auf den jeweiligen Entwickler und nicht auf das Produkt an.


Bis denne, JoKi
Bis denne, JoKi

Enjoy AFP FAQ - Participate AfpWiki - Get Blogged by JoKi - Talk to me at VFP User Group Meeting
private Nachricht | Beiträge des Benutzers
Mr. Bart Simpson
myCSharp.de - Member

Avatar #avatar-3273.gif


Dabei seit:
Beiträge: 502
Herkunft: Mittelfranken

beantworten | zitieren | melden

Also Access hat definitv seine Grenzen (die hier ja auch schon deutlich aufgezeigt wurden), aber es gibt durchaus Situationen, in denen es wirklich was bringt: Stichwort "einfaches Frontend für 'ne SQL DB". Also ich weiss nicht wieviele Stunden ich damit schon gespart hab, wenn ich nur mal schnell ein simples UI wollte, bei dem ein (nicht-DAU!) User ein paar Daten ein eine DB zu bringen hatte ;-)

Bart Simpson
Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.

Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Komplett OT:
Zitat
Original von BiniMeine Standard-Umgebung ist Oracle mit PL/SQL-Developer...
Ich _liebe_ PL/SQL Dev! Wollte ich nur mal loswerden...
private Nachricht | Beiträge des Benutzers
JoKi
myCSharp.de - Member

Avatar #avatar-1587.png


Dabei seit:
Beiträge: 128
Herkunft: Mauritius

beantworten | zitieren | melden

Hi,
Zitat
Original von Mr. Bart Simpson
Aber es gibt durchaus Situationen, in denen es wirklich was bringt: Stichwort "einfaches Frontend für 'ne SQL DB". Also ich weiss nicht wieviele Stunden ich damit schon gespart hab, wenn ich nur mal schnell ein simples UI wollte, bei dem ein (nicht-DAU!) User ein paar Daten ein eine DB zu bringen hatte ;-)

Dazu fällt mir spontan Microsoft InfoPath ein... Ich bin mir nicht ganz sicher, aber meine, dass InfoPath mal genau für diesen Zweck, also als Formulareingabe für den SQL Server, primär genutzt werden sollte...

Naja, bei den vielen Produkten von Microsoft kann man leicht den Überblick verlieren. Wobei ich InfoPath (wird ebenfalls als Office-Anwendung geführt) übrigens ziemlich spannend finde.


Bis denne, JoKi
Bis denne, JoKi

Enjoy AFP FAQ - Participate AfpWiki - Get Blogged by JoKi - Talk to me at VFP User Group Meeting
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Access

beantworten | zitieren | melden

Access ist dann toll, wenn man die "Access Welt" nicht verlässt. Damit meine ich Dinge wie ActiveX-Controls in Access Formularen verwenden oder dem Benutzer .NET Windows Forms per SetParent-API-Funktion unterschieben oder zur Laufzeit die Datenbankverbindung ändern.

Da man ab einer bestimmten Anwendungsgröße aber solche Sachen benötigt, ist Access irgendwann eher hinderlich als hilfreich. Obwohl ich früher ein glaubenstreuer "Access Jünger" war, hasse ich Access mittlerweile. Ich habe jeden Tag damit zu tun, weil das Front-End eines unserer größten Anwendungen noch zu gut 80% aus Access Formularen und Berichten besteht. Am besten gar nicht erst mit Access anfangen!
private Nachricht | Beiträge des Benutzers
Bini
myCSharp.de - Member

Avatar #avatar-1555.jpg


Dabei seit:
Beiträge: 195
Herkunft: der wilde Osten

beantworten | zitieren | melden

Zitat
Original von Robert G
Ich _liebe_ PL/SQL Dev! Wollte ich nur mal loswerden... :D
Ich auch
Umwege erhöhen die Ortskenntnis.
private Nachricht | Beiträge des Benutzers
jan223
myCSharp.de - Member

Avatar #avatar-2059.png


Dabei seit:
Beiträge: 486
Herkunft: Bocholt / NRW

beantworten | zitieren | melden

Also ich nutze oft Access als Datenbank für Windows und Web Anwendungen. Ich habe noch keine großen Probleme gehabt.
Ansonsten nutze ich den SQL Server 2005 damit bin auch ganz zufrieden.
private Nachricht | Beiträge des Benutzers
Mr. Bart Simpson
myCSharp.de - Member

Avatar #avatar-3273.gif


Dabei seit:
Beiträge: 502
Herkunft: Mittelfranken

beantworten | zitieren | melden

Zitat
Original von JoKi
Dazu fällt mir spontan Microsoft InfoPath ein... Ich bin mir nicht ganz sicher, aber meine, dass InfoPath mal genau für diesen Zweck, also als Formulareingabe für den SQL Server, primär genutzt werden sollte...

Naja, bei den vielen Produkten von Microsoft kann man leicht den Überblick verlieren. Wobei ich InfoPath (wird ebenfalls als Office-Anwendung geführt) übrigens ziemlich spannend finde.

Stimmt. Aber Access ist bei den meisten Firmen mit denen ich zu tun hab bereits da (sprich: Lizensiert), wohingegen das mit InfoPath sehr selten der Fall ist
Und: Solange es wirklich einfach bleibt, taugt Access da genauso gut...

Bart Simpson
Praxis ist wenn alles funktioniert und keiner weiss warum.
Theorie ist wenn man alles weiss, aber nichts funktioniert.

Bei uns wird Theorie und Praxis vereint: Nichts funktioniert und keiner weiss warum...
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

InfoPath

beantworten | zitieren | melden

InfoPath ist kein Formular-Front-End für den SQL Server.

Mit InfoPath kann man XML-Dokumente erzeugen und direkt Webservices konsumieren. Gedacht ist das als flexible Möglichkeit XML-Dokumente zu erstellen. Dabei können über Webservices Daten von Backend-Systemen (z.B. SAP) bezogen werden. Die zentrale "Datendrehschreibe" ist dabei der BizTalk Server (Alleine oder im Gespann mit dem Information Bridge Framework, kurz IBF). Der SQL Server ist dabei "nur" ein Infrastrukturdienst.

Damit die vielen kleinen InfoPath-Formulare nicht alle wie Kraut und Rüber herumliegen, hat man den SharePoint Portal Server (bzw. die SharePoint team Services) erfonden. Dort lassen sich sogenannte Formular-Bibliotheken zur Verwaltung der Formulare anlegen. Ab Office 2007 soll der SharePoint übrigens in Office Server umbenannt werden.

Mit diesen neuen Technologieen will Microsoft Office als Smart Client für Business Applikationen etablieren. Die Funktionalität von Programmen wie SAP, Siebel, Navision etc. wird damit direkt aus Office (Word, Excel, Outlook, InfoOPath, ...) Programmen nutzbar (z.B. über die TaskPane, die mit VSTO 2005 programmierbar ist).

Access 2007 war auf der CeBit noch sehr "unfertig". Niemand konnte etwas genaues darüber sagen. Als eigene Entwicklungsplattform, wie es momentan noch oft genutzt wird, soll es nicht mehr positioniert werden. Entwickler sollen alle auf Visual Studio umgesiedelt werden.
private Nachricht | Beiträge des Benutzers
ikaros
myCSharp.de - Member



Dabei seit:
Beiträge: 1787

beantworten | zitieren | melden

Warum Access so verhasst?

Naja, es spricht nicht gegen Access. Hat ne schicke GUI mit der man viel machen kann. Dazu kommen Macrorecorder und VBA(als "Programmiersprache").
Soweit so gut. Ist wirklich ein schickes Progrämmchen.
Leider ist der Kram darunter nicht ein echtes DBMS(hat MS selbst auch nie behauptet). In Sachen Desktop-DB hatte MS Fox-Pro(was zumindest den Anspruch einer Desktop-DB erfüllen konnte(Konkurrierte auch hervorragend zu Paradox und Konsorten)).
Aber selbst wenn Access wenigstens ne vollwertige Desktop-DB-Engine unter sich hätte, könnte Access die verlangten Aufgaben nicht wahrnehmen.
Schuld ist nicht Access(es ist was es ist(Flatfile mit GUI(Wie die etwas grösseren Vorbilder(Accsess erstezt nunmal FoxPro(in vielen Dingen)))). Schuld ist eher die Wahrnehmung von Auftraggebern, die glauben das Ding wär ein echtes DBMS.
Access kann die Aufgaben eines DBMS nunmal nicht wahrnehemen.
Hingegen kann Access mit seiner GUI usw. aber prima Daten zusammenfassen und Auswerten(kleines Manko in Bearbeitung, weil es nicht alle Relationen bewältigen kann).
Access ist quasi ein guter Client(auch offlinefähig für richtige DBMS).
Leider wird Access da unter- und überschätzt.
Access ist ok, nur kein DBMS.
Access ist auch ok für ne kleine EinMannPrivate WasAuchImmerVerwaltung.
Access hat auch ein gutes Berichtmodul(wird gern als Ersatz für ein "teures Reporttool" verwendet.
Access ist schon ok, aber keine richtige DB.
Für reine(MS)-Officelösungen ein guter Client, bzw. ein gutes SW-Modul.
Allergien löst Access eigentlich nur bei wichtigen Daten aus. Selbst da kann Access punkten(einfache Sicherung(Form: Kryptographie, Komprimierung, (PW naja: System.mdw ist/war da etwas unfreundlich bei Distribution))).
Ich find Access toll, solange man es nicht mit ner DB verwechselt....
Super Anwendung - kein DBMS(nicht im entferntesten).

mfg
das war mein Senf zu deiner Frage.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Access und SQL Server

beantworten | zitieren | melden

Man kann Access auch nur als Front-End für SQL Server verwenden. Seit Access 2000 gibt es zusätzlich zum MDB-Format auch das ADP-Format. Damit wird Access an eine bestimmte SQL Server-Datenbank gekoppelt.

Die Datenbank-Features sind meiner Meinung nicht mal das große Problem. Eher diese modifizierte Forms 2.0 GUI, die nur bei Access zum Einsatz kommt. Hier brät Access eine absolute Extrawurst. Es gibt da einige grobe Schnitzer. Platziert man z.B. ActiveX-Controls in Unterformularen auf Registerkarten, reagiert manchmal die Tastatur nicht (Das ist ein von MS bestätigter Bug, der aber nicht gefixt wird). Access Formulare können sich nicht selbst schließen (Es gibt keine Close-Methode). ActiveX Controls können nicht direkt plaziert werden, sondern landen in einem mysteriösen Container-Control, welches die Intellisense auffrisst, weil es nur Object zurückgibt. ich könnte sundenlang so weitermachen.

Software Projekte wachsen einfach. Sie beginnen meist klein und bescheiden. Wenn sie erfolgreich sind, werden sie immer weiter ausgebaut. Irgendwann liegt die Wahl der Plattform und der Architektur 10 Jahre zurück. Im Fall einer Access Anwendung hat man dann höchst warscheinlich ein riesen Kneul Spaghetti VBA, welches mit jeder Menge COM-DLLs, ActiveX-Controls und Win32-API-Calls abgeschmeckt ist. Irgendwann kann man dem lieben alten Access einfach nichts mehr weiteres abverlangen; Die Anwendung muss migriert werden.
private Nachricht | Beiträge des Benutzers
LastGentleman
myCSharp.de - Member

Avatar #avatar-1696.jpg


Dabei seit:
Beiträge: 1274
Herkunft: Österreich

Themenstarter:

beantworten | zitieren | melden

Zitat
Die Anwendung muss migriert werden.

Wie macht man das, bei einer Access Lösung die 10 Jahre alt ist?
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Zitat
Original von LastGentleman
Zitat
Die Anwendung muss migriert werden.
Wie macht man das, bei einer Access Lösung die 10 Jahre alt ist?
Man nimmt sich eine richtige IDE und eine richtige Sprache und macht was man schon hätte tun sollen als sich abgezeichnet hat, dass die Idee hinter dem Access- ... "Ding", gut war.
Das wäre wohl heutzutage C#/VS05 oder wenn Winforms dem User zu sluggish ist gäbe es noch Dephi32/C++ Builder und die gute alte VCL.

btw: Dieses "schnell mal eine GUI bauen" konnte man mit Delphi schon vor 10 Jahren so wie man es erst mit den letzten 2 VS Versionen mit MS Tools kann. Wer also schon vor 10 Jahren ernsthaft "the right tool for the job at hand" evaluiert hätte[1], wäre schon lange über Delphi gestolpert.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

.NET in Access nutzen

beantworten | zitieren | melden

Zitat
Original von LastGentleman
Wie macht man das, bei einer Access Lösung die 10 Jahre alt ist?

Stück für Stück. Ein Modul nach dem anderen. Anders geht es nicht. Das geht mit C# sehr gut. Man muss nur eine Sache strengstens beachten:
Von Access aus nur über seperate COM-Wrapper-Assemblies auf die neuen .NET Sachen zugreifen! Also nicht die .NET Assemblies mit der Funktionalität für COMInterop registrieren und solche Scherze.

Warum? Ganz einfach: Wenn sie direkt von der Access-Welt benutzt werden können müssen, müssen sie sich an die Regeln der Access Welt halten, sonst kann Access sie nicht verwenden. Wenn ich schon den Schritt auf eine neue Technologie mache, will ich nicht die alten Klötze am Beim mitnehmen. Folgende Punkte sollen das nochmal verdeutlichen:

In C# arbeitet man mit DataTables und DataSets. In Access mit ADO-Recordsets (Oder die angestaubten auch noch mit DAO-Recordsets). Folgende Methode kann Access einfach nicht verwenden:


public DataTable GetCustomer(Guid customerID)
{
    ...
}
So müsste sie aussehen, damit sie von Access verwendet werden kann:


[DispId(1)]
public ADODB.RecordSet GetCustomer(string customerID)
{
    ...
}

Da man sich aber nicht implizit ADO classic als Datenzugriffstechnologie für .NET einkaufen will, sondern lieber mit dem neuen tollen ADO.NET arbeiten will, muss es anders gemacht werden. Man schreibt seine .NET Assemblies ohne Rücksicht auf Acces oder sonstige COM-Auswüchse (Also so wie im ersten Beispiel gezeigt). Dann baut man sich für jede dieser .NET Assemblies eine separate COM-Wrapper-Assembly. In diesen Wrapper-Assemblies werden sämtliche Methoden Access gerecht "verpackt". Ein Beispiel aus der Praxis (so sieht es in so einer Wrapper-Assembly bei mir aus):


using System;
using System.Collections.Generic;
using System.Text;
using System.Runtime.InteropServices;
using CustomerManagement;

[ComVisible(true)]
[Guid("f367e1a1-e917-11d0-af5f-00a02448799a")]
[ClassInterface(ClassInterfaceType.None)]
public class CustomerManager : ICustomerManager
{
    ...
    
    public ADODB.Recordset GetCustomer(string customerID)
    { 
        // Original Funktion aufrufen und DataTable in Recordset konvertieren
        return ADOInteropTools.CreateRecordset(_customerManager.GetCustomer(new Guid(customerID)));
    }

    ...
}

[ComVisible(true)]
[Guid("dd67e1a1-e915-17d0-bf5f-10a02448159e")]
public interface ICustomerManager
{
    [DispId(1)]
    ADODB.Recordset GetCustomer(string customerID);

    ...
}

Ich habe dadurch einfach eine Abstraktionsschicht dazwischen, die meine schönen neuen .NET Funktionen an die Access-Welt anbinden. Die COM-Wrapper haben außerdem den Vorteil, dass in Access vollständige Intellisense im VBA Editor funktioniert. Auch die alten Hasen werden nicht merken, dass sie mit einer .NET Assembly arbeiten (Es fühlt sich an wie eine VB6-DLL).

Die ganzen zusätzlichen Attribute sind übrigens die Meta-Informationen, die nötig sind, damit die COM-Komponentenregistrierung richtig durchgeführt werden kann. Vor allem fliegen so nicht bei jeder Neukompilierung Access die Verweise um die Ohren.

Das ganze geht natürlich auch mit .NET Forms. Mit der API-Funktion SetParent kann man einer Access-Anwendung sogar .NET Windows Forms als Unterformulare bzw. Controls auf einem Access Formular unterschieben. Mit ein paar Handgriffen in Visual Basic 6.0 kann man sich so ein "Kaper" Control (OCX) bauen, welches sich um die Extraktion der Window-Handles und die automatische Größenanpassung bei verändern des Rahmens kümmert. Man kann mit .NET leider keine ActiveX-Controls bauen (Windows Forms Controls sind nicht kompatiebel!), deshalb muss für so ein Kaper-Control auf das gute alte VB6 zurückgegriffen werden.

Access kann natürlich auch keine Überladenen Methoden ansprechen.

Multithreading ist für Access auch tabu (COM-Anwendungen laufen in diesen hässlichen Thread-Apartments ab).

Das sind jede Menge Einschränkungen, die man als .NET Entwickler nicht mehr haben will (Sind wir diese Beschränkungen doch endlich los).

Alles was man brauchst, um Access und .NET Komponenten ohne Bauchschmerzen miteinander zu integrieren (um eine schrittweise Migration zu ermöglichen) hier nochmal langsam zu mitschreiben:

Man nehme ...

... pro .NET Assembly eine COM-Wrapper Assembly (Diese wird in Access über Verweise eingebunden)
... einen Satz Hilfstools (z.B. eine statische Funktion, um DataTables in Recordsets umzuwandeln und umgekehrt etc.)
... ein in VB6 (oder auch VC++, für die harten Jungs) erstelltes Kaper-per-hwnd-ActiveX-Control (Braucht ca. 1 Stunde Entwicklungszeit)
... ein stinknormales Modul in Access mit dem Namen "RemoteControl", dessen public subs und functions man von C# aus per Access.Application.Run("...") aufrufen kann (Der Zug soll ja schließlich in zwei Richtungen fahren)

Hoffentlich helfen meine Ausführungen, möglichst viele Access Projekte "sanft" zu migrieren. Nur nicht von den COM-Guids (CLSID etc.) einschüchtern lassen. oder wie man bei uns in Süddeutschland sagen würde: "Dabb am Deifl uff da Kopf!".
Da ich jeden Tag damit zu tun habe (Migriere selbst ein großes Access 2000 Projekt auf diese Art und Weise) stehe ich für weitere Fragen gerne zur Verfügung.
private Nachricht | Beiträge des Benutzers
LastGentleman
myCSharp.de - Member

Avatar #avatar-1696.jpg


Dabei seit:
Beiträge: 1274
Herkunft: Österreich

Themenstarter:

beantworten | zitieren | melden

Danke Rainbird.
Dein Betrag, hat mir (und auch sicher die anderen die ihn lesen) sehr viel gebracht.
Nicht nur die Migration von Access Anwendungen, sonder auch für die Einbindung vom Com-Controls im Allgemeinem.

Ich bin einmal so "unverschähmt" und frage ein bischen nach.

Zitat
Die ganzen zusätzlichen Attribute sind übrigens die Meta-Informationen, die nötig sind, damit die COM-Komponentenregistrierung richtig durchgeführt werden kann. Vor allem fliegen so nicht bei jeder Neukompilierung Access die Verweise um die Ohren.

Dabei handelt es sich doch um die info [DispId(1)] oder?


Zitat
Kaper-per-hwnd-ActiveX-Control

In ihm ist ein Bild von dem ich den Handle hole und mittes SetParten meine Anwenung reinschiebe.


Zitat
einen Satz Hilfstools (z.B. eine statische Funktion, um DataTables in Recordsets umzuwandeln und umgekehrt etc.)

Wie kann man eigendlich DAO (ja ich verwende noch die angestaubten DAO-Recordsets), selber befüllen. Von DAO->Datatable kann ich mirs vorstellen.


Besten Dank im Voraus

PS. Vielleicht sollte man bis zu den vorigen drei eine neuen Thread machen.
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Details

beantworten | zitieren | melden

Die Warpperklasse braucht folgende Attribute:

[Guid("...")]
Daraus wird COM CLSID. Wenn man das Guid-Attribut nicht angibt, wird beim kompilieren automatisch ein zufälliger neuer CLSID erzeugt. Als Folge davon findet Access den Verweis auf die DLL nicht mehr. Deshalb immer angeben.

[ClassInterface(ClassInterfaceType.None)]
Damit wird keine Standard-Klassenschnittstelle nach außen veröffentlicht. Wenn das nicht abgeschlatet wird, wird die Klasse nur über die COM-Dispatch-Schnittstelle zugänglich gemacht. Die Dispatch-Schnittstelle realisiert dei späte Bindung bei COM-Komponenten. Deshalb wird dann auch keine Intellisense im Access VBA-Editor funktionieren. Wenn man das Standardverhalten aber abschaltet, muss man sich selber um eine öffentliche Schnittstelle kümmern (Bei COM läuft ohne Schnittstellen gar nichts). Deshalb gehört zu jeder Wrapper-Klasse eine Schnittstelle, die Implementiert werden muss.

[ComVisible(true)]
Kann man auch weglassen, sieht aber schöner aus. Man sieht sofort, dass diese Klasse für COM-Clients sichtbar ist.


Die Methoden der Warpperklassen brauchen:

[DispId(1)]
Jede Methode sollte unbedingt eine solche Disposition ID zugewiesen bekommen. Dabei wird von 1 beginnend einfach durchgezählt. Hintergund: COM adressiert Methoden nicht über ihren Namen, sondern über die Reihenfolge (z.B. die 3. Methode von oben). Wenn man keine DispIds vergibt, werden sie automatisch vergeben. Wenn man dann aber eine neue Methode einfügt, geht plötzlich nichts mehr. Die COM-Schnittstelle wird dadurch verletzt und die Binär-Kompatiblität geht flöten. Damit fliegt bei Access wieder der Verweis raus.


Die Schnittstelle braucht:

[Guid("...")]
Daraus wird die COM IID (Interface ID). Wird benötigt, um die Schnittstelle eindeutig zu machen. Die ist sogar noch wichtiger als die CLSID, da bei COM wie gesagt alles über Schnittstellen geht.


Zum Kaper-Control: Du brauchst kein Bild. Das Control ist einfach leer. Da das Control im Sinne der Windows API selbst ein Window ist, kann es auch als Parent für ein anderes Window dienen.


Zu DAO: Hab ich noch nie gemacht, muss ich erst nachschauen. Bin damals mit Office 97 auf ADO umgestiegen (Zur Hölle mit den Dynasets und Snapshots).
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Sorry, falls es OT wird...
Zitat
Das sind jede Menge Einschränkungen, die man als .NET Entwickler nicht mehr haben will (Sind wir diese Beschränkungen doch endlich los).
Ich entwickle sehr gerne unter .Net/Mono, aber was kann ich mit .Net machen, das ich vorher nicht konnte?
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8775
Herkunft: Berlin

beantworten | zitieren | melden

Was kann eine beliebige Programiersprache, das du nicht auch mit einer simplen Termersetzungsmaschine machen kannst? Auch nix. Alle Programmiersprachen auf Von-Neumann-Rechnern sind gleich mächtig.

Insofern ist die Frage nach "was kann ich machen, was ich voher nicht konnte" nur rhetorisch. Die richtige Frage lautet: "Was kann ich jetzt LEICHTER machen als vorher?"
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Deshalb habe ich extra das zitiert was mich da gewundert hatte. Denn Einschränkungen hat man ja eigentlich eher wenn man von nativ auf .Net wechselt. 90% aller Dinge sind nun schöner und meist auch einfacher gelöst, aber Einschränkungen waren mir früher in Delphi nur bekannt wenn es um Treiberprogrammierung ging. Wenn man von VB ausgehen würde, klar dass mit .Net Einschränkungen verschwanden, aber ...
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Vb

beantworten | zitieren | melden

Ich habe früher fast ausschließlich mit Visual Basic 6 bzw. VBA gearbeitet :D.
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Zitat
Original von Rainbird
Ich habe früher fast ausschließlich mit Visual Basic 6 bzw. VBA gearbeitet :D.
Deshalb deine Signatur?
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Qualität

beantworten | zitieren | melden

Die Programmiersprache spielt für Qualität keine Rolle. Wie man sie einsetzt ist das Entscheidende. Meine Forderung nach mehr Qualität rührt daher, dass jede Software die wir in der Firma bis jetzt zugekauft haben katastrophale Fehler hatte. Wenn man die Preise dieser Produkte kennt und sich mit den teilweise sehr arroganten Mitarbeitern der Hersteller und Vertriebspartner herumschlagen muss, kommt da schnell die Forderung nach mehr Qualität auf.

Ich war z.B. Ende letzten Jahres auf einer Entwicklerschulung für ein von uns gekauftes in Delphi 7 geschriebenes CRM-System. Beim öffnen des Projekts in der Borland IDE ist die ganze IDE erstmal abgestützt (Schwerer Ausnehmefehler). Beim zweiten Mal gings dann. Nach jedem Neustart musste die Delphi IDE zuerst einmal abstürzen. Der Trainer und die anderen Teilnehmer haben den Fehler, wie selbstverständlich, einfach weggecklickt und die Delphi IDE neu gestartet. Erst als ich den Trainer gefragt habe: "Moment mal, da ist doch eben die komplette IDE abgeschmiert." bekam ich eine Reaktion zu diesem Fehler. Man sagte mir, dass das eben so ist und man sich schnell daran gewöhnt. In der Tat ist es auch bei uns in der Firma so, dass die Delphi IDE bei diesem Code-Projekt beim ersten Start erstmal abschmiert (Andere Delphi Projekte starten ohne fehler). Anstatt den Fehler in ihrem Delphi-Projekt zu suchen und zu entfernen, wird er einfach ignoriert. Bei dem betroffenen CRM-System gab es noch weitere haarsträubende Probleme. Z.B. hat die API für den Datenzugriff des Sysrtems mysteriöse Exceptions geworfen, wenn mehr als 200 Datensätze auf einen Rutsch abgefragt werden sollten. Der Support meinte dann, ich solle doch einfach meine Adressen immer in 20er Blöcken abrufen, da bei 20 Datensätzen das Problem nicht auftreten würde.

Das schlimme ist, dass dieses CRM-System kein Einzelfall ist.

Wers selber besser kann, darf auch maulen :D.
private Nachricht | Beiträge des Benutzers
Robert G
myCSharp.de - Member

Avatar #avatar-1907.png


Dabei seit:
Beiträge: 348
Herkunft: München

beantworten | zitieren | melden

Gut gekontert
Zitat
Original von Rainbird
Das schlimme ist, dass dieses CRM-System kein Einzelfall ist.
Wers selber besser kann, darf auch maulen :D.
Definitv hat Delphi das gleiche Problem, das jedes RAD Tool hat: Technisch unfähige Pseudoentwickler, die RADifizierten Spaghetticode produzieren, der sich nicht mehr warten lässt. (Rate mal warum die Honks den inakzeptablen Fehler akzeptieren anstatt ihn zu beheben... )

Der Anteil dieser "Entwickler" dürfte sich aber anhand der doch sehr strengen Sprache und den normalerweise sehr strengen Richtlinien in der Pascal-Welt in Grenzen halten. Die meisten werden wohl frühzeitig eingesehen haben, dass VB oder Access besser für sie geeignet sind.
Bisher bin ich in RL noch keinem VB'ler / Access-frickler begegnet, den ich fachlich respektieren konnte. Und ich habe definitv öfter mit der Bande zu tun, als mir lieb ist. (Deshalb vllt auch meine Allergie darauf )

bte: Auch wenn ich weit ausgeholt habe, dürfte nichts zu lesen gewesen sein á la "alle VB'ler sind doof". Zum Beispiel zeigt dein Beitrag weiter oben, dass du dich besser mit Problemen auseinandersetzt als es 90% deiner ehemaligen Kollegen getan hätten.
private Nachricht | Beiträge des Benutzers
Rainbird
myCSharp.de - Experte

Avatar #avatar-2834.jpg


Dabei seit:
Beiträge: 3953
Herkunft: Mauer

Frickler

beantworten | zitieren | melden

Danke für die Blumen. VBler sind natürlich für ihre "Pasta" berüchtigt.
Deshalb kann ich Deine Allergie darauf verstehen.

Wenn eine Anwendung stabil und schnell funktioniert und ich definierte Schnittstellen (in irgendeiner Form) habe, wäre ich ja schon zufrieden. Oft sind es auch grobe Designfehler, die mir das Wasser in die Augen treiben.

Bei einem in Java geschriebenen namhaften eProcurement System, muss man z.B. in verschiedenen Eingabemasken den Datensatzschlüssel eingeben (Dieser ist bei diesem System ein klassischer int, der durch die Datenbank hochgezählt wird). Den weiß man als Anwender aber nicht. Woher auch. Er dient ja nur für interne Datenbank-Belange. Richtig wäre die Eingabe der Artikel-Nr. Dieser Fehler ist wohl den meisten noch nicht aufgefallen, da sie ihre Artikel per BMECat in dieses System importieren und nicht die Benutzeroberfläche verwenden.

So könnte ich stundenlang weiter erzählen.

Die Qualität der meisten kommerziellen Business Software ist einfach inakzeptabel. Oder ich habe immer zufällig die schwarzen Schafe erwischt. Mich wundert nur, warum IT-Firmen hohe Gehälter an Leute zahlen, die solche Software herstellen.
private Nachricht | Beiträge des Benutzers