Is it advantageous to use .NET Framework DLL's in Access?

[David W. Fenton]

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]

"(e-mail address removed)" <[email protected]>
wrote in
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.to.you]

Hi Everyone,

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]

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.

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&amp;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]

"(e-mail address removed)" <[email protected]>
wrote in

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.

 

[CDMAPoster]

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
(e-mail address removed)

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

-- Dictionary of Australian Slang, Second Edition, Sidney J. Baker,
1943 (Price: Three shillings & sixpence)

 

[lyle fairfield]

I expect that exploring .Net as a faciltator of data marshalling or a
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.