Laden...

Warum ist Access so verhaßt?

Erstellt von LastGentleman vor 17 Jahren Letzter Beitrag vor 17 Jahren 23.409 Views
LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren
Warum ist Access so verhaßt?

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

Q
20 Beiträge seit 2006
vor 17 Jahren

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

F
10.010 Beiträge seit 2004
vor 17 Jahren

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.

347 Beiträge seit 2006
vor 17 Jahren

_Original von FZelle_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. 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(

_Original von Quadrina_P.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

S
8.746 Beiträge seit 2005
vor 17 Jahren

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.

195 Beiträge seit 2004
vor 17 Jahren

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.

128 Beiträge seit 2004
vor 17 Jahren

Hallo,

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

502 Beiträge seit 2004
vor 17 Jahren

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...

347 Beiträge seit 2006
vor 17 Jahren

Komplett OT:

_Original von Bini_Meine Standard-Umgebung ist Oracle mit PL/SQL-Developer...

Ich liebe PL/SQL Dev! Wollte ich nur mal loswerden... 😁

128 Beiträge seit 2004
vor 17 Jahren

Hi,

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

3.728 Beiträge seit 2005
vor 17 Jahren
Access

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!

195 Beiträge seit 2004
vor 17 Jahren

Original von Robert G
Ich liebe PL/SQL Dev! Wollte ich nur mal loswerden... 😄

Ich auch

Umwege erhöhen die Ortskenntnis.

460 Beiträge seit 2004
vor 17 Jahren

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.

502 Beiträge seit 2004
vor 17 Jahren

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...

3.728 Beiträge seit 2005
vor 17 Jahren
InfoPath

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.

I
1.739 Beiträge seit 2005
vor 17 Jahren

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.

3.728 Beiträge seit 2005
vor 17 Jahren
Access und SQL Server

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.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

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

347 Beiträge seit 2006
vor 17 Jahren

Original von LastGentleman

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. 😉

3.728 Beiträge seit 2005
vor 17 Jahren
.NET in Access nutzen

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.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

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.

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?

Kaper-per-hwnd-ActiveX-Control

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

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

3.728 Beiträge seit 2005
vor 17 Jahren
Details

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).

347 Beiträge seit 2006
vor 17 Jahren

Sorry, falls es OT wird...

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? 🤔

S
8.746 Beiträge seit 2005
vor 17 Jahren

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?"

347 Beiträge seit 2006
vor 17 Jahren

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 ...

3.728 Beiträge seit 2005
vor 17 Jahren
Vb

Ich habe früher fast ausschließlich mit Visual Basic 6 bzw. VBA gearbeitet 😄.

347 Beiträge seit 2006
vor 17 Jahren

Original von Rainbird
Ich habe früher fast ausschließlich mit Visual Basic 6 bzw. VBA gearbeitet 😄. Deshalb deine Signatur? 😁

3.728 Beiträge seit 2005
vor 17 Jahren
Qualität

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 😄.

347 Beiträge seit 2006
vor 17 Jahren

Gut gekontert 🙂

Original von Rainbird
Das schlimme ist, dass dieses CRM-System kein Einzelfall ist.
Wers selber besser kann, darf auch maulen 😄. 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. 😉

3.728 Beiträge seit 2005
vor 17 Jahren
Frickler

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.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

Danke für deine Antwort,

vorallem das [DispId(1)] ist sehr interessant.

Ich arbeite nur mit DAO- Ado ist mir fremd, hab keine Probleme mit Snapshots und Dynasets. Wo liegt den bei denen das Problem.

"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

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

von Ikarus.
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....

Was fehlt ihr denn zur richtigen DB?

Warum löst es allergien aus bei wichtigen Daten?

Wir stehen vor der Entscheidung ein Projekt in Csharp oder in Access zu machen.
Bitte helft mir, ich würde gerne ein Projekt in dot.net beginnen und nicht immer Access machem!!!

"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

K
239 Beiträge seit 2005
vor 17 Jahren

@LastGentleman
Die Frage ist ja nicht wirklich ernst gemeint oder? Zwischen C# und Access besteht immerhin der Unterschied, dass C# keine Datenbank ist.

Je nach Projekt/Softwaregrösse wäre eine Kombination C# und MDB (Access) denkbar. Die Nachteile wurden schon genannt.

Ein nicht unerheblicher Vorteil bei MDB's ist halt, dass sie Lizenzfrei weitergegeben werden können. (Weiss aber auch, dass es noch andere DB's gibt, wo das auch der Fall ist)

3.728 Beiträge seit 2005
vor 17 Jahren
Genau lesen

Hallo kaepten,

Du hast da was nicht richtig gelesen. Access wird nicht mit C# verglichen sondern mit dem SQL Server (Der ist ja wohl eine Datenbank, oder? 😉); Beziehungsweise auch mit anderen RDBMs, die allgemein als vollwertige Datenbanken betrachtet werden.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

Hallo Rainbird,

ja das hab ich gemeint. Danke einer hät wenigstes zu mir.
Leider ist es zu spät das Projekt wir nun in Access Front- & Backend durchgezogen.

Schade ich hätte gerne was in CSharp gemacht, aber auch da muss man durch.

Wenn ich fragen darf, warum seid ihr umgestiegen?

PS. MEHR ACCESS LÖSUNGEN BRAUCH DAS LAND. X( X( X( X( X( X( X( X(

"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

K
239 Beiträge seit 2005
vor 17 Jahren

@Rainbird

Wir stehen vor der Entscheidung ein Projekt in Csharp oder in Access zu machen.

Ich ging von diesem Zitat aus bei meinem Post. Da steht nix von SQL-Server und implizit bin ich nicht davon ausgegangen. 🤔

@LastGentleman
Schade, wirklich. Eine Kombination c# - Access wäre doch ein guter Kompromiss gewesen.

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

leider ist Access so ein RAD-Tool, das lässt sich nicht beschreiten und ein Formular ist wirklich schnell gemacht.

In anderen Sprachen braucht man wie ich das sehe viel länger. Bei Berichten ist das gleiche. Das Deployment ist relativ einfach (sovern Access vorhanden) einfach MDB kopieren (vielleicht mit der Berechtigungsdatenbank) und das wars auch schon

"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

3.728 Beiträge seit 2005
vor 17 Jahren

Original von LastGentleman
Wenn ich fragen darf, warum seid ihr umgestiegen?

Wir steigen immernoch um. Wenn man für alle in Access verwendeten .NET Funktionalitäten immer brav COM-Wrapper-Assemblies erstellt, kann man langsam Stück für Stück umsteigen. Ein Modul nach dem anderen. Mittels SetParent-API-Funktion lassen sich .NET Formulare und Steuerelemente ganz leicht in Access Formulare einbauen. Dieser "sanfte" Migrationsweg ist auch der kostengünstigste.

I
1.739 Beiträge seit 2005
vor 17 Jahren

Access ist wirklich gut(RRAD - hab noch ein Rapid angehängt).
So wie ich es verstanden habe geht es um ein neues Projekt. Ich empfehle daher(Als LowCost-Alternative) die MS-SQL Expressvariante.
Vorteile:
-Geringe Einschränkungen gegenüber einer grösseren Lösung
-Kostenfrei
-Gute Einbindung in .Net(ADO 2.0 Features gibts kaum(gegenüber 1.1 geringfügig), es sei denn Hausentwicklungen besser unterstützt(extrem besser supported).
-Access ist eher Auslaufmodell(als DB eh veraltet, FoxPro war die bessere Konkurrenz aus eigenem Haus(Desktop-DB)). Die Vorteile von Access lagen in der besseren Office-Integration. Ein echtes DBMS war Access nie. Konnte aber als RAD-Tool(OfficeClient) überzeugen(reiner Desktop oder Client für echte DBMS).

An ein DBMS werden Ansprüche gestellt.
-Verfügbarkeit.
-Sicherheit(der Daten)
-Echte Relationen(Datenkonsistenz)
-und einige Sachen mehr(die als optional gelten können)
Access kann die "einfachsten" Sachen nicht gewährleisten. Eine Access_DB als Server zu empfehlen ist nicht möglich(oder eine Geld/Gewissensfrage).

Meine obige Empfehlung hast du ja gesehn(nicht perfekt, da Express-Varianten ja nicht umsonst Schwächen haben)
Weitere Empfehlungen ähnlicher Sicht(schlechtere .Net Unterstützung) wären:
SQL-Lite
Firebird
ORA -Express
DB -Express

Freie "echte" DB's:
PostgreSQL
MySQL - hat sich inzwischen rausgemacht.

Treff halt die Wahl zwischen Nutzen, Sicherheit und performance. Eine weiteres Kriterium für die Wahl ist natürlich der Skill der Beteiligten. Manchmal helfen auch Tools(als Hilfsmittel bei fehlenden Skills). Die Auswahl ist sicher nicht einfach.
Access hat durchaus Vorzüge, aber nicht als DB im MultiUserzugriff.
Erste Wahl? Nicht bei den Alternativen im kostengünstigen DB-Bereich. Als zusätzliche Option - vielleicht.
Die Eckdaten sind halt unbekannt.

D
15 Beiträge seit 2006
vor 17 Jahren

Ist eigentlich egal wie man zu dem Thema Access steht, Fakt ist, dass man als Entwickler nicht wirklich drumherrum kommt.

Viele (ja auch grosse/namenhafte) Firmen verlangen bis heute Frontends für ihre Accessdaten.

Auch manche Neuentwicklung soll mit Access im Rücken laufen.

I
1.739 Beiträge seit 2005
vor 17 Jahren

>Fakt ist, dass man als Entwickler nicht wirklich drumherrum kommt.

Nö, das ist Kundenabhängig. Als Entwickler kann auch den Brötchengeber wechseln(lala, Käse). Jedenfalls hat der Kunde schuld, schliesslich ist man Dienstleister und macht das was der Kunde denkt, was "nützlich ist"...

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

Oder Billig ist. Eine Access-DB hat man schnell zusammengezimmert.

"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

K
71 Beiträge seit 2005
vor 17 Jahren

Hallo

Wir haben diverse Access-Datenbanken mit entwickelten Erweiterungen im Einsatz.
Sie arbeiten alle zuverlässig und das seit Jahren.

Richtig grosse Probleme haben wir jedoch mit der Skalierbarkeit, Schnittstellen zu anderen Applikation und der immer grösser werdenden Benutzeranzahl.
Wir sind daher gezwungen all diese Applikation abzulösen.

Access ist mächtig, sollange es nicht überstrapaziert wird 🙂
Gilt selbstverständlich nur wenn man ein Access-Projekt genau so strukturiert angeht wie jedes andere Projekt auch.

Gruss Fellmer

LastGentleman Themenstarter:in
1.274 Beiträge seit 2005
vor 17 Jahren

Zu Skalierbarkeit ->naja ist alles Handarbeit

Schnittstellen ->ich kann mir Out-Of-The-Box Excel, Word, XML (2003) Datei generieren und lesen.
Auch kann man Webservice nutzen mit einen Ähnlichen Tool wie im Visual Studio

Benutzeranzahl ->Ok das stimmt ab 50 ist Schluss.

"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

476 Beiträge seit 2004
vor 17 Jahren

Ich liebe Access, meine Lieblingsfehlermeldung ist: "Das Objekt hat keinen wert", sonst sagen doch nur Kinder und Narren die Wahrheit.

-yellow

Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).

Mein Blog: Yellow's Blog auf sqlgut.de