Roy, I believe they are using Access for much more than just a database engine. Access deals with displaying forms, handling script-based code (although, I have to admit, its VBA dialect is really stone age technology), and displaying reports.
Many people actually use Access _with_ MSDE; they run MDB files as a front-end and work on 'attached' tables in a MSDE or SQL Server instance. Kamen -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Roy Forkner Sent: 03 Март 2003 г. 20:10 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] .NET Remoting and Access 97 How about replacing Access with MSDE? Roy Forkner -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Melvin Bernstein Sent: Monday, March 03, 2003 11:33 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] .NET Remoting and Access 97 I posted this to the .NET-CLR list about 5 days ago but no one has responded ... Our shop is still in the stone age technologically, using Access (often Access 97) in combination with SQL Server for many projects. I am trying to get our group to move to .NET, skipping over COM. To that end, I have been able to reference and call a simple .NET object from Access 97 by creating a type library, registering the assembly and placing it in the global (1) However, placement in the global cache requires strong name creation which would be a hassle to do on our various Access 97/2000 client machines. I have been unable to figure out how to simply use a private assembly for this purpose. Placing it in either WinNT\System32 or in the Access.exe directory fails to get Access to list the assembly in its "Reference" object list. *** (2) Furthermore, what I really wish to do is to allow Access 97/2000 clients to call .NET components residing on a separate box (my gosh, a pursue, and if so, would I simply wrap the .NET remoting stub in a COM callable wrapper and call that wrapper from Access? Thanks for any help!
