Access -> Visual Studio and the .Net Framework

Over the past several years I have had to deal with an increasing number of
problems involving setting up mdac, isams, service packs and the like on
client machines. Often these are not installed, not installed properly, or
not up-to-date. With 60 notebooks, there may be 30 distinct configurations.
Current Visual Studio (2005?) applications require the presence of the .Net
framework.

Has this lessened or increased the frequency of the problem I mentioned in
paragraph one occurring? Do you have experiences to share?

Further are you aware of any speculation that the requirement of this
framework’s existence is likely to lead to further legal problems for
Microsoft, based on the notion that since the framework is installed with
(or is part of) Windows 2003 Server and Windows Vista, Microsoft
development software will have an unfair advantage over other firm’s
development software?


--
lyle fairfield

Re: Access -> Visual Studio and the .Net Framework

On Fri, 26 Oct 2007 11:03:39 GMT, lyle fairfield
wrote:

The dotnet framework simplifies these matters tremendously, if you use
it. This is to say, you can still use ADO from your dotnet component.
Not recommended, but you can. Then of course all the dependencies
still apply.

The dotnet framework is automatically updated with Windows Updates. I
don't think mdac is/was.

ISAMs I don't know. Since afaik it's not built into the framework,
your mileage may vary.

The legal angle: I would not worry about. It will either not happen or
take many years to wind itself through the courts, with some
compromise at the end.

-Tom.

>
>Over the past several years I have had to deal with an increasing number of
>problems involving setting up mdac, isams, service packs and the like on
>client machines. Often these are not installed, not installed properly, or
>not up-to-date. With 60 notebooks, there may be 30 distinct configurations.
>Current Visual Studio (2005?) applications require the presence of the .Net
>framework.
>
>Has this lessened or increased the frequency of the problem I mentioned in
>paragraph one occurring? Do you have experiences to share?
>
>Further are you aware of any speculation that the requirement of this
>framework’s existence is likely to lead to further legal problems for
>Microsoft, based on the notion that since the framework is installed with
>(or is part of) Windows 2003 Server and Windows Vista, Microsoft
>development software will have an unfair advantage over other firm’s
>development software?

Re: Access -> Visual Studio and the .Net Framework

On Oct 26, 9:38 am, Tom van Stiphout wrote:
> On Fri, 26 Oct 2007 11:03:39 GMT, lyle fairfield
> wrote:
>
> The dotnet framework simplifies these matters tremendously, if you use
> it. This is to say, you can still use ADO from your dotnet component.
> Not recommended, but you can. Then of course all the dependencies
> still apply.
>
> The dotnet framework is automatically updated with Windows Updates. I
> don't think mdac is/was.
>
> ISAMs I don't know. Since afaik it's not built into the framework,
> your mileage may vary.

Are you able to compare the .Net framework with the Java Runtime
Environment on matters such as size, ease of installation,
capabilities, impact on other resident technologies and the other day-
to-day operations of the computer, integration with COM technologies,
and cross-platform applicability? Are they essentially the same kind
of thing?

Sorry, I see I've asked for a short book, but I find little on the net
about what the .Net Framework actually is and how it actually works.

So comments on any one of those issues might help me understand.

Re: Access -> Visual Studio and the .Net Framework

On Sun, 28 Oct 2007 04:03:23 -0700, lyle
wrote:

Sorry, I'm stictly a microsofty.

The dotnet framework is essentially a huge class library, providing
the programmer with a very large number of classes to program against.
You name it, and there is a dotnet class encapsulating it. From a
String class or two to File Streams to Encryption to Graphics. Here is
a high-level overview:
http://msdn2.microsoft.com/en-us/library/hfa3fa08.aspx

DotNet also provides for easy memory management (a real problem with
COM) in that you essentially don't have to worry about freeing memory:
the garbage collector will come by and clean up after you. I
understand Java has a similar facility.

-Tom.



>On Oct 26, 9:38 am, Tom van Stiphout wrote:
>> On Fri, 26 Oct 2007 11:03:39 GMT, lyle fairfield
>> wrote:
>>
>> The dotnet framework simplifies these matters tremendously, if you use
>> it. This is to say, you can still use ADO from your dotnet component.
>> Not recommended, but you can. Then of course all the dependencies
>> still apply.
>>
>> The dotnet framework is automatically updated with Windows Updates. I
>> don't think mdac is/was.
>>
>> ISAMs I don't know. Since afaik it's not built into the framework,
>> your mileage may vary.
>
>Are you able to compare the .Net framework with the Java Runtime
>Environment on matters such as size, ease of installation,
>capabilities, impact on other resident technologies and the other day-
>to-day operations of the computer, integration with COM technologies,
>and cross-platform applicability? Are they essentially the same kind
>of thing?
>
>Sorry, I see I've asked for a short book, but I find little on the net
>about what the .Net Framework actually is and how it actually works.
>
>So comments on any one of those issues might help me understand.

Re: Access -> Visual Studio and the .Net Framework

On Sun, 28 Oct 2007 17:27:59 -0700, Tom van Stiphout
wrote:

Another advantage with DotNet is that you can write components and
load them in SQL Server 2005 and call them from T-SQL. For years we
have been using an implementation in C of the Ratcliff-Obesthelp SIMIL
procedure to calculate the silimarity between two strings. I recently
implemented this in DotNet, and the procedure now runs an order of
magnitude faster.

-Tom.


>On Sun, 28 Oct 2007 04:03:23 -0700, lyle
>wrote:
>
>Sorry, I'm stictly a microsofty.
>
>The dotnet framework is essentially a huge class library, providing
>the programmer with a very large number of classes to program against.
>You name it, and there is a dotnet class encapsulating it. From a
>String class or two to File Streams to Encryption to Graphics. Here is
>a high-level overview:
>http://msdn2.microsoft.com/en-us/library/hfa3fa08.aspx
>
>DotNet also provides for easy memory management (a real problem with
>COM) in that you essentially don't have to worry about freeing memory:
>the garbage collector will come by and clean up after you. I
>understand Java has a similar facility.
>
>-Tom.
>
>
>
>>On Oct 26, 9:38 am, Tom van Stiphout wrote:
>>> On Fri, 26 Oct 2007 11:03:39 GMT, lyle fairfield
>>> wrote:
>>>
>>> The dotnet framework simplifies these matters tremendously, if you use
>>> it. This is to say, you can still use ADO from your dotnet component.
>>> Not recommended, but you can. Then of course all the dependencies
>>> still apply.
>>>
>>> The dotnet framework is automatically updated with Windows Updates. I
>>> don't think mdac is/was.
>>>
>>> ISAMs I don't know. Since afaik it's not built into the framework,
>>> your mileage may vary.
>>
>>Are you able to compare the .Net framework with the Java Runtime
>>Environment on matters such as size, ease of installation,
>>capabilities, impact on other resident technologies and the other day-
>>to-day operations of the computer, integration with COM technologies,
>>and cross-platform applicability? Are they essentially the same kind
>>of thing?
>>
>>Sorry, I see I've asked for a short book, but I find little on the net
>>about what the .Net Framework actually is and how it actually works.
>>
>>So comments on any one of those issues might help me understand.

Re: Access -> Visual Studio and the .Net Framework

Tom van Stiphout wrote in
news:gllbi3l0fbkcfrd4p38l98dj51oocqeno6@4ax.com:

> On Sun, 28 Oct 2007 17:27:59 -0700, Tom van Stiphout
> wrote:
>
> Another advantage with DotNet is that you can write components and
> load them in SQL Server 2005 and call them from T-SQL. For years we
> have been using an implementation in C of the Ratcliff-Obesthelp SIMIL
> procedure to calculate the silimarity between two strings. I recently
> implemented this in DotNet, and the procedure now runs an order of
> magnitude faster.

I've been aware of and fascinated with this capability for sometime, but
have not used it.
Somewhere we learned to keep GUI, Code/Logic and Data separate, in three
black boxes.
Does this practice ignore that admonition?
If it does, are there potential problems? Does it concern you?

--
lyle fairfield

Re: Access -> Visual Studio and the .Net Framework

On Mon, 29 Oct 2007 13:02:39 GMT, lyle fairfield
wrote:

I don't see a particularly big difference between calling the built-in
SOUNDEX function, and my user-created SIMIL function. I am in favor of
these separations, but first and foremost I am practical.

-Tom.



>Tom van Stiphout wrote in
>news:gllbi3l0fbkcfrd4p38l98dj51oocqeno6@4ax.com:
>
>> On Sun, 28 Oct 2007 17:27:59 -0700, Tom van Stiphout
>> wrote:
>>
>> Another advantage with DotNet is that you can write components and
>> load them in SQL Server 2005 and call them from T-SQL. For years we
>> have been using an implementation in C of the Ratcliff-Obesthelp SIMIL
>> procedure to calculate the silimarity between two strings. I recently
>> implemented this in DotNet, and the procedure now runs an order of
>> magnitude faster.
>
>I've been aware of and fascinated with this capability for sometime, but
>have not used it.
>Somewhere we learned to keep GUI, Code/Logic and Data separate, in three
>black boxes.
>Does this practice ignore that admonition?
>If it does, are there potential problems? Does it concern you?

Re: Access -> Visual Studio and the .Net Framework

Tom van Stiphout wrote in
news:jcpbi3968sprts85cfie6eb1ms29bj5pvi@4ax.com:

> first and foremost I am practical.

That's not how you appear here to me. First and foremost is smart, and
second is capable. Practical may be third.

--
lyle fairfield

Re: Access -> Visual Studio and the .Net Framework

Hi Lyle,

You have been such a great help to me that I though perhaps I might
have something to finally offer you in return. I use both Java
and .Net in my work, and I choose the tool dependant on the task and
destination environment.

In my company the possibility of having different 'standard installs'
is very common, same as it seems for yourself. I have to work with
about 60 machines, running mostly Win2K and a variety of apps and
service packs. MDAC is an issue for me as different versions are on
different machines and so I keep my apps to MDAC 2.8SP1 and I make
sure to install it by hand, myself so that I know it is there and
working properly. This of course does not guarantee that someone else
wont come along and murder it, and in my IT environment it is a
regular occurance.

I use the .Net framework, (same manual install as the MDAC problem)
for some simpler applications primarily written in VB.Net 2005 using
the ADO.Net capabilities. I have found that when working with Oracle 8
for example that I still need to install special components to be able
to talk properly with the servers. In short I find that the .Net
framework is very MS specific. So, depending on your target for
development and deployment it can be either a bonus or a curse.
Security settings for running .Net applications can also be a pain,
particularly when dealing with network situations and granting access
to resources - others may disagree with me on this but I find the
security model needlessly complex and convoluted even or the most
simple tasks. In short the sandbox is a little too small and hard to
build your castle in.

On the plus side for .Net, the framework gives you access to just
about everything you could want to do with a windows based machine. It
really is a very comprehensive set of tools to work with. In many
respects MS seem to have copied Java in the overprovision of tools to
meet a task. I think I read somewhere that there were 288,000 methods,
properties and events in the .Net framework. As far as development
goes, as long as you are comfortable with OO programming then you
shouldn't find too many problems building what you want.

With regards to Java, I find it a great tool for many tasks, as long
as you work to a particular runtime environment. Deploying the runtime
is pretty easy and doesnt seem to cause any problems with other apps
or on different platforms. I find Java incredibly flexible to work
with for scaling applications up to larger and larger tasks, and the
ability to create and deploy applets is a real boon, particulary for
network based applications. If you use something like Apache Tomcat or
JBoss as an application server for your applet you can scale very
easily to cater for very large demands.

On the downside for Java, although it is not impossible, it is
oftentimes hard to make a Java application 'Wintuitive', and working
with some of the MS file formats that are in common use can be a pain.
You end up attaching to your project lots of .jar files with the
needed code to talk to this file or that. The big difference here is
that you dont have to install the .jar, like you do with drivers or
MDAC stuff, you can just reference it in your project and ship
the .jar with it -job done.

In short I find each has its place, and that Java is at this stage, in
my opinion, superior to .Net for application development, especially
if you are considering server type applications. Perhaps this will
change with the MS developments of .Net into the future. I also find
that Java has one more little bonus - the ability to scale downwards
to portable devices such as phones and PDA's - which can be a really
nice thing to add to a project to keep the bosses happy and mobile
field staff efficient and productive.

I hope this small comparison is helpful to you. It is not often that I
have the opportunity to offer something to someone as experienced as
yourself, so consider this a small thankyou for all your help. And I
do hope you find it useful.

Cheers

The Frog

Re: Access -> Visual Studio and the .Net Framework

The Frog wrote in
news:1193736443.292979.171680@y42g2000hsy.googlegroups.com:

> Hi Lyle,
>
> You have been such a great help to me that I though perhaps I might
> have something to finally offer you in return. I use both Java
> and .Net in my work, and I choose the tool dependant on the task and
> destination environment.
>
> In my company the possibility of having different 'standard installs'
> is very common, same as it seems for yourself. I have to work with
> about 60 machines, running mostly Win2K and a variety of apps and
> service packs. MDAC is an issue for me as different versions are on
> different machines and so I keep my apps to MDAC 2.8SP1 and I make
> sure to install it by hand, myself so that I know it is there and
> working properly. This of course does not guarantee that someone else
> wont come along and murder it, and in my IT environment it is a
> regular occurance.
>
> I use the .Net framework, (same manual install as the MDAC problem)
> for some simpler applications primarily written in VB.Net 2005 using
> the ADO.Net capabilities. I have found that when working with Oracle 8
> for example that I still need to install special components to be able
> to talk properly with the servers. In short I find that the .Net
> framework is very MS specific. So, depending on your target for
> development and deployment it can be either a bonus or a curse.
> Security settings for running .Net applications can also be a pain,
> particularly when dealing with network situations and granting access
> to resources - others may disagree with me on this but I find the
> security model needlessly complex and convoluted even or the most
> simple tasks. In short the sandbox is a little too small and hard to
> build your castle in.
>
> On the plus side for .Net, the framework gives you access to just
> about everything you could want to do with a windows based machine. It
> really is a very comprehensive set of tools to work with. In many
> respects MS seem to have copied Java in the overprovision of tools to
> meet a task. I think I read somewhere that there were 288,000 methods,
> properties and events in the .Net framework. As far as development
> goes, as long as you are comfortable with OO programming then you
> shouldn't find too many problems building what you want.
>
> With regards to Java, I find it a great tool for many tasks, as long
> as you work to a particular runtime environment. Deploying the runtime
> is pretty easy and doesnt seem to cause any problems with other apps
> or on different platforms. I find Java incredibly flexible to work
> with for scaling applications up to larger and larger tasks, and the
> ability to create and deploy applets is a real boon, particulary for
> network based applications. If you use something like Apache Tomcat or
> JBoss as an application server for your applet you can scale very
> easily to cater for very large demands.
>
> On the downside for Java, although it is not impossible, it is
> oftentimes hard to make a Java application 'Wintuitive', and working
> with some of the MS file formats that are in common use can be a pain.
> You end up attaching to your project lots of .jar files with the
> needed code to talk to this file or that. The big difference here is
> that you dont have to install the .jar, like you do with drivers or
> MDAC stuff, you can just reference it in your project and ship
> the .jar with it -job done.
>
> In short I find each has its place, and that Java is at this stage, in
> my opinion, superior to .Net for application development, especially
> if you are considering server type applications. Perhaps this will
> change with the MS developments of .Net into the future. I also find
> that Java has one more little bonus - the ability to scale downwards
> to portable devices such as phones and PDA's - which can be a really
> nice thing to add to a project to keep the bosses happy and mobile
> field staff efficient and productive.
>
> I hope this small comparison is helpful to you. It is not often that I
> have the opportunity to offer something to someone as experienced as
> yourself, so consider this a small thankyou for all your help. And I
> do hope you find it useful.
>
> Cheers
>
> The Frog

Hi Mr. Frog

Your response is just the kind of user reflection for which I had hoped.
I found it very thought-provoking, and saved it in my directory of
prrogramming resources and papers.

Thanks!

--
lyle fairfield

Re: Access -> Visual Studio and the .Net Framework

Anytime :-)

Re: Access -> Visual Studio and the .Net Framework

On Oct 30, 7:27 pm, The Frog wrote:
....
> With regards to Java, I find it a great tool for many tasks, ... the
> ability to create and deploy applets is a real boon, particulary for
> network based applications.

You should check out Java Web Start. It offers 'all'* the benefits
of applets, but with few, if any of the usual head-aches that
applets can cause.

* Except maybe direct interaction with JavaScript, since JWS
apps. are not embedded within a web page, but free floating**.
....
> On the downside for Java, although it is not impossible, it is
> oftentimes hard to make a Java application 'Wintuitive', and working
> with some of the MS file formats that are in common use can be a pain.
> You end up attaching to your project lots of .jar files

JWS can help with this also, by allowing the extra jar's to be
deployed
'lazy'***, and downloaded by the client (and cached locally) as
required.

You also mentioned versioning - in some words I trimmed,

JWS is also good at checking for the required Java runtime
versions****.


** E.G.

*** More an example of the JNLP API's DownloadService, but
uses Jar's that are deployed lazily.

**** More details


Andrew T.

Re: Access -> Visual Studio and the .Net Framework

On Oct 30, 5:27 am, The Frog wrote:
> And I
> do hope you find it useful.
>
> Cheers
>
> The Frog

I found your description enlightening as well. With my forays into
Java and .Net (C# instead of VB) just beginning, the timing of your
"mountaintop" view is particularly apt. I keep coming back to those
tools as the most versatile enablers of technology once a problem goes
beyond the purview of Access.

Thanks,

James A. Fortune
CDMAPoster@FortuneJames.com

Re: Access -> Visual Studio and the .Net Framework

The Frog wrote:

>Anytime :-)

Whoa, it doesn't get any better than Lyle saying he saved your posting.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/