Is it advantageous to use .NET Framework DLL's in Access?
CDMAP...@fortunejames.com
Framework. Is there a downside to using functions from those DLL's
within Access?
James A. Fortune
CDMAP...@FortuneJames.com
Scott McDaniel
>Most computers I support that have Access also have the latest .NET
>Framework. Is there a downside to using functions from those DLL's
>within Access?
AFAIK, you cannot use the .NET Framework in Access.
>
>James A. Fortune
>CDMAP...@FortuneJames.com
Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com
Tom van Stiphout
wrote:
Scott is right. They are a different kind of DLL that cannot be used
from VBA. So now we have three kinds of DLL:
* Classic DLL
* COM DLL
* .NET DLL
Only the first two can be used by VBA. A .NET programmer can write a
.NET DLL and put a COM wrapper around it, so it becomes accessible to
the VBA programmer.
-Tom.
Microsoft Access MVP
Norman Yuan
framework, usually) exposed via COM Interop, yes, you can use it. Advantage
or not, it is really depends on your need: if you need some functionalities
that you can only find in that DLL as you know, then that is advantage; if
you can can do the functionalities in Access VBA easily, then the advantage
is gone, why add extra dependency to your application?.
<CDMAP...@FortuneJames.com> wrote in message
news:8b947c3a-f5cd-4b46...@40g2000prx.googlegroups.com...
David W. Fenton
news:8b947c3a-f5cd-4b46...@40g2000prx.googlegroups.com
:
> Most computers I support that have Access also have the latest
> .NET Framework. Is there a downside to using functions from those
> DLL's within Access?
If it were even possible, what would the upside be?
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
John Mishefske
> If it were even possible, what would the upside be?
Wrapping within a COM layer is easy. The advantage I've realized is the
ability to leverage .NET code in legacy Access apps as well as new
generation native .NET apps with minimal code changes. .NET makes things
like email and web access via proxy much easier and less error prone
than in the old days.
Updates are as easy as copying in new .DLLs (without a need to register
them) to client Access installs (provided COM compatibility is maintained).
Some resources for those interested:
A Beginner’s Guide to calling a .NET Library from Access
http://richnewman.wordpress.com/2007/08/25/a-beginner%E2%80%99s-guide-to-calling-a-net-library-from-access/
--- uses .NET library as a reference -- done by setting COM related
attributes of the .NET project
Exposing COM interfaces of a .NET class library for Late Binding
http://www.codeproject.com/KB/vb/MusaExposingCOM.aspx
--- uses .NET library via late-binding (CreateObject) - uses COM Class
template in .NET
Managed Add-Ins for Access 2007
http://msdn2.microsoft.com/en-us/library/aa902693.aspx
COM Interoperability in .NET Part 2 - Generating a Type Library (RegAsm.exe)
http://www.developerfusion.co.uk/show/2134/3/
The regasm.exe utility not only registers an assembly and it also
creates the
required type library file, as shown here:
regasm Server.dll /tlb:Netserver.tlb /codebase
and you can un-install with:
regasm /u Server.dll /tlb:Netserver.tlb /codebase
VB6 interoperability with .NET
-------------------------------
Interop Forms Toolkit 2.0
http://msdn2.microsoft.com/en-us/vbasic/aa701259.aspx
.NET to COM interoperability
-----------------------------
Microsoft .NET/COM Migration and Interoperability - Patterns and Practices
http://msdn2.microsoft.com/en-us/library/ms978506.aspx
--
John Mishefske, Microsoft MVP 2007 - 2009
UtterAccess Editor
Tigeronomy Software
web: http://www.tigeronomy.com
email: sales ~at~ tigeronomy.com
CDMAP...@fortunejames.com
> Most computers I support that have Access also have the latest .NET
> Framework. Is there a downside to using functions from those DLL's
> within Access?
>
> James A. Fortune
Thanks for the answers. They were all helpful.
James A. Fortune
CDMAP...@FortuneJames.com
CDMAP...@fortunejames.com
> David W. Fenton wrote:
> > If it were even possible, what would the upside be?
>
> Wrapping within a COM layer is easy. The advantage I've realized is the
> ability to leverage .NET code in legacy Access apps as well as new
> generation native .NET apps with minimal code changes. .NET makes things
> like email and web access via proxy much easier and less error prone
> than in the old days.
>
> Updates are as easy as copying in new .DLLs (without a need to register
> them) to client Access installs (provided COM compatibility is maintained).
>
> Some resources for those interested:
>
> --- uses .NET library as a reference -- done by setting COM related
> attributes of the .NET project
>
> --- uses .NET library via late-binding (CreateObject) - uses COM Class
> template in .NET
>
>
> COM Interoperability in .NET Part 2 - Generating a Type Library (RegAsm.exe)http://www.developerfusion.co.uk/show/2134/3/
>
> The regasm.exe utility not only registers an assembly and it also
> creates the
> required type library file, as shown here:
>
> regasm Server.dll /tlb:Netserver.tlb /codebase
>
> and you can un-install with:
>
> regasm /u Server.dll /tlb:Netserver.tlb /codebase
>
> VB6 interoperability with .NET
> -------------------------------
>
>
> .NET to COM interoperability
> -----------------------------
>
>
> --
> John Mishefske, Microsoft MVP 2007 - 2009
> UtterAccess Editor
> Tigeronomy Software
> web:http://www.tigeronomy.com
> email: sales ~at~ tigeronomy.com
Thanks again for the great links. That information will revolutionize
the way I code in Access eventually. I'll get the best of both worlds
both now (legacy app enhancement) and later (A2K7 AddIn's). I'm
excited about exploring the possibility of things like security, data
marshalling/marshaling, multithreading, multicore optimization and
maybe even n-tier using Access. Plus, if Access with .NET enhancement
is used to demonstrate a concept, the enhancements themselves will
likely need no conversion if the customer decides they want an
all .NET solution. The .NET Framework is looking a lot more useful to
me now than it did when I considered programming against it using
Visual Studio alone.
James A. Fortune
CDMAP...@FortuneJames.com
Mr.Frog...@googlemail.com
you will find a lot of data push / pull / validation issues are easily
solved. Its really well thought out.
My 2 cents
The Frog
lyle fairfield
news:31164d32-8a84-4609...@c11g2000yqj.googlegroups.com:
I think .Net, foisted upon us by the insidious marketing tactics of a
malevolent organization, is an inefficient, ineffective, controlling,
claptrap technology, inferior to its antecedents, slow and clumsy in
operation, and inordinately demanding of time and resources. .Net met one
and only one need, viz, the need of Microsoft to have something new to
sell.
My 2 cents
--
lyle fairfield
- The man who told us that Canada wouldn't go there has now told us that
Canada will be the first to come back. How reassuring!
Builder
> "Mr.Frog...@googlemail.com" <Mr.Frog...@googlemail.com> wrote
> in
> news:31164d32-8a84-4609...@c11g2000yqj.googlegroups.com:
>
>> ADO.Net is really top notch IMO. Make yourself familiar with that and
>> you will find a lot of data push / pull / validation issues are
>> easily solved. Its really well thought out.
>>
>> My 2 cents
>>
>> The Frog
>
> I think .Net, foisted upon us by the insidious marketing tactics of a
> malevolent organization, is an inefficient, ineffective, controlling,
> claptrap technology, inferior to its antecedents, slow and clumsy in
> operation, and inordinately demanding of time and resources. .Net met
> one and only one need, viz, the need of Microsoft to have something
> new to sell.
>
> My 2 cents
Funny how you don't mind making a living with the products of a "malevolent"
organization...
David W. Fenton
wrote in
news:31164d32-8a84-4609...@c11g2000yqj.googlegroups.co
m:
> ADO.Net is really top notch IMO. Make yourself familiar with that
> and you will find a lot of data push / pull / validation issues
> are easily solved. Its really well thought out.
Is that an Access-related comment?
David W. Fenton
news:Xns9BE241F9B...@216.221.81.119:
> I think .Net, foisted upon us by the insidious marketing tactics
> of a malevolent organization, is an inefficient, ineffective,
> controlling, claptrap technology, inferior to its antecedents,
> slow and clumsy in operation, and inordinately demanding of time
> and resources. .Net met one and only one need, viz, the need of
> Microsoft to have something new to sell.
Wow! Lyle and I agree!
My problem with .Net, which I haven't touched nor will I ever, is
that when I look at the runtime that Windows Update keeps putting on
my machine and updating, it keeps breaking and littering my event
logs with its startup and configuration errors. If it can't be
completely transparent, then it's worthless.
Of course, on this particular PC, the JRE is broken, too, so it
seems to be endemic to this kind of runtime platform. And that's why
I just can't see it replacing real applications distributed in
OS-specific binary format.
For the web, sure, fine -- no problem.
But for desktop apps, forget it.
David W. Fenton
news:KGnBl.24093$9a....@bignews1.bellsouth.net:
[Re: Lyle's criticism of .NET:]
> Funny how you don't mind making a living with the products of a
> "malevolent" organization...
Uh, back in the late 90s, with the release of VBA in Office, MS was
not "malevolent." It's only with the Enterprise push that came
around the time of the release of Office 2000 that MS has lost its
way, in my opinion. That's no reason for me to abandon what still
works for my clients.
CDMAP...@fortunejames.com
I can't even say that I disagree with your points Lyle. In a previous
post somewhere, I suggested that .NET was simply a means for Microsoft
bugs to escape into the wild :-), so I'm not going into this with my
eyes closed. Yet a means to retrofit earlier versions of Access with
new capabilities is simply too compelling for me to ignore. I'm not
ruling out trying other technologies if .NET code turns out not to be
viable. Plus, I don't think that Microsoft is going to address
several of Access' weaker points, ever. The possibility of having a
RAD environment that uses Access enhanced by .NET needs to be tried
out though, IMO.
James A. Fortune
CDMAP...@FortuneJames.com
Salad
On the west coast it almost appears the desktop app is dead. The web
rules completely.
Rich P
application for small business or office level operations (and not web
based). A flying club I belong to has been using an Access2000 mdb for
years for scheduling and billing (non-web based) with minimal problems,
but it is a one person at a time system. We could use a .Net/sql server
system but we only have 100-200 members. So the .Net/sql server system
would be a bit of overkill
For corporate level usage - mulitple users, thousands of transactions
for a given period (like every few minutes) or web based, this is
typically where the limits of Access become exceeded and require a
bigger system like the .Net/sql server system. And note this: Access
and .Net were all born from MFC. Access is the high level system for
quick and easy usage, and .Net is the lower level system (just not as
low level as MFC - by low I mean foundation level) where you have a lot
less prebuilt stuff - less overhead - like if you need a continuous form
in .Net - you have to create it yourself - its not prebuilt in. You can
harness a lot more horse power with .Net than with Access. So it all
depends on how much horsepower you need to harness (integrate).
Access is an integrated database/development environment, and quite high
level. .Net is not integrated with a database system and is
significantly lower level than Access, much closer to the foundation
level of MFC. Plus you have a choice of languages, VB.Net and C# being
the two primary. VB.Net is a little higher level than C#, but
significantly lower level than Access and it is also object oriented
(that is a very big deal because OOP is where you can really harness the
horse power of a large database system like sql server).
Rich
*** Sent via Developersdex http://www.developersdex.com ***
rkc
OOP is a basically paradigm for organizing code. How does that relate
to
harnessing the horsepower of anything?
David W. Fenton
news:89OdnaJJRd2H9UvU...@earthlink.com:
> David W. Fenton wrote:
>
[re: .NET:]
>> For the web, sure, fine -- no problem.
>>
>> But for desktop apps, forget it.
>
> On the west coast it almost appears the desktop app is dead. The
> web rules completely.
*yawn*
Yes, and thin clients will replace full-fledged computers sometime
in 1990 or so.
Or so they all said back then.
The web simply cannot beat the experience of a well-designed desktop
app precisely because of its statelessness.
CDMAP...@fortunejames.com
Hmmm. Your ideas for using .NET were unexpected. I've used MFC with C
++. I remember that MFC has all the building blocks for visual code,
but I don't remember it having a lot of what I'm looking for with .NET
routines. I think Microsoft might have even released the source code
for MFC under certain restrictions so using MFC directly is tempting,
but not tempting enough right now. I'm eager to continue learning C#
and to use it for interacting with and improving Access. I think I've
had my nose in mostly VB style programming for a little too long so
I'll skip VB.NET. Later on I can evaluate whether or not .NET is
suitable for other purposes, such as Web apps. Right now I suspect
that I might not have much use for .NET in Web apps, but I'll try some
things that way and try to keep an open mind.
James A. Fortune
CDMAP...@FortuneJames.com
Mr.Frog...@googlemail.com
I cant speak to the whole of the .Net environment, only the parts that
I have used. Typically I have found that .net makes simple tasks hard,
and this occurs because of the level of control that it gives you. For
the large part I just dont need it and nor do the users I create tools
for.
That being said, the one thing I really do like about .net,
specifically for the control, is ADO.net. This is like ADO on
steroids, and as Rich P pointed out - this is great for working with
servers. Where I have found it an advantage, particularly working
across networks for 'distributed' applications, is to create an app
(or take one over) that has been built in Access, turn it into FE / BE
as a first step. Second step is to 'abstract' the data push / pull
from the database by writing (or mostly re-using) a .net windows
service that handles the network comms and uses ADO.net to talk to the
DB. In this way I can achieve two things where Access alone will
suffer - I can handle the comms any way I wish, and I can handle the
data push / pull any way I wish. Using a .net dll as the 'point of
interaction' or 'interface' or whatever you want to call it for the
client end of the app (FE) keeps the data handling clean and leaves me
to develop the app like I would with any other - BUT with the addition
of any logic I wish to the comms and data push / pull. For remote
office or disconnected workers this is a real plus and it helps to
ensure a really reliable app and data 'environment'.
This probably isnt useful to most people, but it has certainly helped
me and those I work for immensely. I now have over 250 remote workers
using a 'disconnected' MS Access (2003) application just the same as
if they were in the office (to all intents and purposes). I have
avoided the need to 'scale up' to SQL server, or any other choice of
server for that matter, and the windows service lives on one of our
application servers and 'points' to the location on the network where
the MDB file lives. I can automate the backups from the service as
well (if I so choose), or any other logic that I wish to implement -
without affecting the users at all. I am thinking of tring to
integrate a report scheduler so a 'standard report' can be run and
emailed to a group but I havent got that far yet.
So do whatever nay saying you wish, and hate MS all you want. As I
said I cant speak to the whole of the .net platform, only the bits I
use, but I have found it extremely powerful and helpful for solving
problems that Access would otherwise struggle with, and it has (after
the initial development hurdle) provided me with a set of capabilities
that really allow a greater deployment of Access tools that I would
have otherwise had. It has also saved on costs when considering server
infrastructures and maintainance, skillsets etc... and of cousre its
fairly easy to replace me from a programming point of view as the
whole thing is in VB.net / VBA.
My expanded 2 cents
Cheers
The Frog
lyle fairfield
news:Xns9BE399935E113f9...@74.209.136.98:
> The web simply cannot beat the experience of a well-designed desktop
> app precisely because of its statelessness.
I agree, David and that's the beauty of an ADP. When connected to an
Internet enabled SQL-Server DB ADPs provide the best of both worlds.
Because ADPs are so tiny (without images) they can be downloaded quickly
and, provided the user has the required version of Access installed, they
fire-up instantly. In addition, this downloading procedure ensures the
application is always up-to-date.
You REALLY should try this.
Mr.Frog...@googlemail.com
lyle fairfield
news:2c89c366-a1a1-47cb...@z15g2000yqm.googlegroups.com:
> Why would I want to buy an SQL Server when I dont need one?
I can't imagine. Has someone suggested this to you?
mha...@lotuscreek.com
Plus, I just hate OO programming anyway, for good reason...a from
everything I've seen, .NET and Java both force its use.
The best way I've heard it put is that OOP is basically a backwards
methodology:
http://www.stlport.org/resources/StepanovUSA.html
On Apr 4, 3:05 pm, "David W. Fenton" <XXXuse...@dfenton.com.invalid>
wrote:
CDMAP...@fortunejames.com
That's an interesting article. So your recommendation for a better
way to enhance existing and prior versions of Access is ...?
James A. Fortune
CDMAP...@FortuneJames.com
STAR HOTEL, SLEEP IN THE - To sleep in the open. -- Dictionary of
Australian Slang, Second Edition, Sidney J. Baker, 1943 (Price: Three
shillings & sixpence)
David W. Fenton
> "David W. Fenton" <XXXu...@dfenton.com.invalid> wrote in
> news:Xns9BE399935E113f9...@74.209.136.98:
>
>> The web simply cannot beat the experience of a well-designed
>> desktop app precisely because of its statelessness.
>
> I agree, David and that's the beauty of an ADP. When connected to
> an Internet enabled SQL-Server DB ADPs provide the best of both
> worlds. Because ADPs are so tiny (without images) they can be
> downloaded quickly and, provided the user has the required version
> of Access installed, they fire-up instantly. In addition, this
> downloading procedure ensures the application is always
> up-to-date.
>
> You REALLY should try this.
Why would I waste my time on a completely dead technology that never
worked reliably in the first place? And one that MS now recommends
against?
[BTW, Lyle -- you have something wrong with your newsreader. It
removes the comma between the two newsgroups listed in the
NEWSGROUPS: header]
David W. Fenton
wrote in
news:2c89c366-a1a1-47cb...@z15g2000yqm.googlegroups.co
m:
> Why would I want to buy an SQL Server when I dont need one?
Buy it? You do know that most small applications can be built with
SQL Server Express, right?
Mr.Frog...@googlemail.com
David wrote (echoing Lyle too)
> Buy it? You do know that most small applications can be built with
> SQL Server Express, right?
The case I gave was of a disconnected worker. SQL Server Express is
certainly a suitable container for many things, however in order for
it to allow a worker to work in a disconnected manner you need to have
it installed (usually not a problem), then either replicate the data
to an SQL server at the head office (for example) which requirs buying
an SQL server, or you can program your own application / service to
handle the repllication. I did the second option, and I used ADO.net
to achieve it. No SQL Server necessary, just Access 2003 runtime on
the client machines, and an MDB file with the service back in the
office (acting a bit like a server I suppose).
I am not sure how SQL Server Express can handle the disconnected
worker without either using an SQL server to handle the replication of
data, or by developing a service / app to do it in place of SQL
Server. Likewise I have no idea how one could achive a disconnected
fully functional ADP (aside from which, as David quite rightly points
out, is a dead tech).
OO Programming is actually pretty easy, and most Access developers are
probably already doing close to it anyway. Using class modules is not
quite, but almost the same thing. In OO everything is a class
(basically). I dont think anyone who is a serious professional
developer would struggle at all with using .net and VB.net or C#.net.
As I said, I cant speak to the whole .net platform, but I have found
that ADO.net is in IMO a very good tool to use, and the .net
networking is also quite simple and capable to work with. For what I
need it to do it is brilliant and has achieved it flawlessly. I will
be exploring the incorporation of cryptographic functions into the mix
using .net soon too.
From my little corner of the world, I would like to see .net directly
accessable from Access (and other MS technologies), perhaps as an
extension to VBA, or even a replacement - but still directly
integrated into the Access development environment. I like developing
in Access and I would like to continue to be able to do so.
I think we are up to about 20cents now....
Cheers
The Frog
lyle fairfield
news:70fffea5-4b7a-40e5...@3g2000yqk.googlegroups.com:
> OO Programming is actually pretty easy, and most Access developers are
> probably already doing close to it anyway. Using class modules is not
> quite, but almost the same thing. In OO everything is a class
> (basically). I dont think anyone who is a serious professional
> developer would struggle at all with using .net and VB.net or C#.net.
On Apr 8, 5:41 am, "Mr.Frog.to....@googlemail.com" <Mr.Frog.to....
@googlemail.com> wrote:
> OO Programming is actually pretty easy, and most Access developers are
> probably already doing close to it anyway. Using class modules is not
> quite, but almost the same thing. In OO everything is a class
> (basically). I dont think anyone who is a serious professional
> developer would struggle at all with using .net and VB.net or C#.net.
So I write this:
<form id="formMenus" runat="server">
<asp:Menu id="Forms" runat="server">
<Items>
<asp:MenuItem Text="Change Password"
NavigateUrl="changePassword.aspx" />
<asp:MenuItem Text="Class Organization"
NavigateUrl="classOrganization.aspx" />
<asp:MenuItem Text="Classes"
NavigateUrl="classes.aspx" />
</Items>
</asp:Menu>
</form>
and .Net writes this (along with some css at the top of the page):
<div>
<form name="formMenus" method="post" action="menu.aspx"
id="form1">
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwULLTE5Nzk1NTk4MTVkZA==" />
</div>
<a href="#Forms_SkipLink" style="display:inline-
block;height:1px;width:1px;"><img src="/WebResource.axd?d=4v7
_Bef517owaC6Ht4EKKw2&t=633718154239476693" alt="Skip Navigation
Links" style="border-width:0px;" /></a><div id="Div1">
<span>
<a class="Forms_1" href="changePassword.aspx">Change
Password</a>
</span>
<br />
<span>
<a class="Forms_1" href="classOrganization.aspx">Class
Organization</a>
</span><br /><span>
<a class="Forms_1" href="classes.aspx">Classes</a>
</span>
<br />
</div>
<a name="Forms_SkipLink"></a>
</form>
</div>
which is the functional equivalent of:
<p>
<a href="changePassword.aspx">Change Password</a>
<br />
<a href="classOrganization.aspx">Class Organization</a>
<br />
<a href="classes.aspx">Classes</a>
</p>
So why would I want to do the .Net OOP thing when all it does is write
some HTML with a bunch of unnecessary properties when I can just write
the HTML (and simpler/better, smaller HTML than ASP.Net does, IMO)?
Years ago when FoxPro went OOPey I drilled down behind the Objects. What
did I find? X-Base code. The Objects were comprised of XBase code and
created from XBase code and wrote or called X-Base code. I liked the X-
Base code that I wrote better than the X-Base code the objects wrote. And
this is scarcely surprising since I know exactly what I want and exactly
the circumstances of the application. The Object must be generalized in
its approach; it's unlikely to be a responsive to the needs of the
application as a capable developer.
As for ADO.Net I find it limited in relation to ADO, but I'm willing to
hear about what it can do that ADO can't do, and what it can do better
than ADO. Please, tell me some specific things.
Back to using NET Framework dlls in Access: please name several of the
.Net functions, procedures or whatever that you want to take advantage of
in Access.
David W. Fenton
wrote in
news:70fffea5-4b7a-40e5...@3g2000yqk.googlegroups.com:
> The case I gave was of a disconnected worker. SQL Server Express
> is certainly a suitable container for many things, however in
> order for it to allow a worker to work in a disconnected manner
> you need to have it installed (usually not a problem), then either
> replicate the data to an SQL server at the head office (for
> example) which requirs buying an SQL server, or you can program
> your own application / service to handle the repllication. I did
> the second option, and I used ADO.net to achieve it. No SQL Server
> necessary, just Access 2003 runtime on the client machines, and an
> MDB file with the service back in the office (acting a bit like a
> server I suppose).
>
> I am not sure how SQL Server Express can handle the disconnected
> worker without either using an SQL server to handle the
> replication of data, or by developing a service / app to do it in
> place of SQL Server.
I missed the "disconnected worker" part in your replies.
I agree with all of your objections to SQL Server on the client
workstation (whether for disconnected users or not). But that's what
MS is proposing as the replacement for Jet replication (which might
very well have been a much easier solution to your situation). Well,
there's Sharepoint, but that can't really do it, either.
I just shake my head in wonder at the fact that the Access team
allowed replication to be removed from ACCDB format while not having
any serious replacement technology for it. It seems quite clear that
the MS agenda of deprecating Access/Jet into an end-user platform
won the day in the most recently completed Access development cycle.
Shades of Access 2000, in fact.
rkc
Like Lyle, I would be interested to know what you can do with
.net that is of benefit to an Access desktop application that
you can not do with other technology.
Sever side, classic asp or php can receive requests, query a
database and format a response just as easily as anything.
A response is sent as text in some format the client is waiting
for. That's the way it works with any technology that uses the "web"
for communication.
Client side, XMLHTTP can be used to send requests and field the
resulting response without the complexity of .net wrapped in com.
VBA can be used to parse XML, CSV, or json for that matter, just
as easily as anything else.
One can OOP things up all they want using VBA if one is so inclined.
The need for inheritance in developer written code is a rare thing in
my admittedly limited world so I don't miss that a bit.
Rich P
nothing to do with Access but just responding to questions about the
viability of .Net/ADO.Net...
Currently, I am working on a project which is to convert some php web
applications to .Net applications in C# (this kinda reminds me how I had
to convert some ADP projects to .Net). PHP/classic ASP both do pretty
much everything you can do in .Net - just requires a ton more code. The
one thing the PHP/classic ASP can't do which .Net does is to create
compiled code (and way less of it). The client wants compiled web
applications because there are way less security holes in a compiled
application than the interpreted apps of PHP/classic ASP and a lot more
.Net is a lot more scalable (that was one of the key paradigms in the
development of .Net - to simplify the big stuff).
Additionally, the goal of .Net is the same as the goal of Access - to
simplify the coding process. Has anyone ever tried (I mean this
century) to create a multi-tiered system in MFC? Not fun - way not
fun. Access single handedly revolutionized this process last century.
But the corporate sector needed more than what Access/the com
environment (VB6...) could deliver. Thus emerged .Net - the simplified
version of MFC.
.Net is not simpler than Access. It is simpler than MFC.
Mr.Frog...@googlemail.com
technologies......
I am not going to suggest that the VBA environment and VBA be
completely replaced with VB.Net or anything like that. The tools that
I found useful in the .net architecture were the following (in
combination with each other): ADO.net, System.net, System.IO,
System.Net.Sockets. I primarily used these to achieve my goals, and it
worked because I could compile it into a service. You cannot do that
with Access. The nearest you could get would be to have a specialised
runtime app running on a box somewhere on the network, and try and use
windows sockets to handle the multiple threads etc. Access is
definitely not the right tool for that job (IMO).
The ability to extend what you can do with Access is what interests
me. Replication in Access would have been great if it could have
worked in our environment, but due to IT restrictions and data
handling restrictions (legal) it cant. With .Net I can leave my
runtime application unchanged and simply present a standard interface
from the service to it. When I need to make a change to the way the
data is replicated I make it once in my source code, compile it, and
send it to the IT group to test - if happy with it then its a straight
swap of only a tiny file instead of multiple Mb of Access application.
In short .Net is basically just an extended set of tools to play with.
I say add them in and take your pick of which works better for the job
at hand. I see no reason to exclude it. I have no preference for OOP
or more 'traditional' forms of programming, its all the same to me. My
choice comes down to which one gets the job done faster and more
reliably. Access is a very versatile tool, but its not everything.
Neither is .Net, but it covers a larger territory than Access ever
could. The difference is one of effort in reaching the goal.
I hope that this explains a little more about what my experience with
the working the two products. I found the whole excercise most
productive. Shifting the whole thing to Java would make me even
happier......a man can dream........
Cheers
The Frog
CDMAP...@fortunejames.com
> Back to using NET Framework dlls in Access: please name several of the
> .Net functions, procedures or whatever that you want to take advantage of
> in Access.
The Data marshaling and translation named in:
http://msdn.microsoft.com/en-us/library/ms978506.aspx
is one of the things that is high on my list given Access' inability
to utilize multiple cores efficiently. Data encryption is weak in
Access and having compiled routines, whether part of the .NET
framework or even home-spun managed code is almost necessary for any
reasonable speed in Access when encrypting and de-encrypting. Even
some mundane things like being able to use linked lists in Access
interest me.
James A. Fortune
CDMAP...@FortuneJames.com
GOOGLY - A ball in cricket which breaks from the off, although
apparently bowled as a leg-break. (2) An awkward question which a
person would rather not answer. (3) As for "bosey" (2).
BOSEY - A "googly"" ball or bowler. (2) A single bomb dropped from a
plane. (R.A.A.F. slang.)
lyle fairfield
route to efficient multiple core use is worthwhile. The topic seem a
bit advanced for CDMA, but perhaps considering it will encourage us to
look for .Net solutions to problems in those areas.
On Apr 9, 4:53 pm, CDMAPos...@FortuneJames.com wrote:
> On Apr 8, 7:15 am, lyle fairfield <lylef...@yah00.ca> wrote:
>
> > Back to using NET Framework dlls in Access: please name several of the
> > .Net functions, procedures or whatever that you want to take advantage of
> > in Access.
>
> The Data marshaling and translation named in:
>
> http://msdn.microsoft.com/en-us/library/ms978506.aspx
>
> is one of the things that is high on my list given Access' inability
> to utilize multiple cores efficiently. Data encryption is weak in
> Access and having compiled routines, whether part of the .NET
> framework or even home-spun managed code is almost necessary for any
> reasonable speed in Access when encrypting and de-encrypting. Even
> some mundane things like being able to use linked lists in Access
> interest me.
>
> James A. Fortune
> CDMAPos...@FortuneJames.com