473,324 Members | 2,196 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,324 software developers and data experts.

Is ADO dead?

MSDN Home > MSDN Library > Win32 and COM Development

Data Access

Microsoft offers many data access technologies to suit various
development needs. This section of the MSDN Library contains technical
information about current data access technologies, focusing on the
Microsoft Data Access Components (MDAC): ADO, OLE DB and OLE DB
Providers, and ODBC. Articles on ADO.NET, Microsoft Data Engine (MSDE),
and some XML for Analysis (XMLA) material are available here as well.
You'll also find information about legacy technologies such as DAO and
OLAP Services.

Check out the Data Access and Storage Developer Center

Look here for orientation, guidance, new information, downloads and
code samples on the latest in data access and storage technologies,
including ADO.NET, SQL Server, MDAC, and WinFS.

In This Library Section Essentials

* MDAC Documentation
* ADO Documentation
* ODBC Documentation
* OLE DB Documentation
* OLE DB Provider for Internet Publishing
* Diving Into Data Access
* MSDE Technical Articles

* Data Access Downloads
* ADO.NET Documentation
* ADO Code Samples
* XML for Analysis Specification
* MSDE Product Information
* Data Technologies Support Center
* Newsgroups

Feb 19 '06 #1
19 3092
"Lyle Fairfield" <ly***********@aim.com> wrote
* MSDE Technical Articles

* MSDE Product Information


Well, we know that MSDE is dead.
--
Darryl Kerkeslager

Feb 19 '06 #2
"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:TO********************@comcast.com:
"Lyle Fairfield" <ly***********@aim.com> wrote
* MSDE Technical Articles

* MSDE Product Information


Well, we know that MSDE is dead.


Well, not dead, but renamed, which suggests that any documentation
using the term "MSDE" is out of date, and, perhaps obsolete.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 19 '06 #3
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

Well, not dead, but renamed, which suggests that any documentation
using the term "MSDE" is out of date, and, perhaps obsolete.


No - it is dead - in the same sense that people have referred to ADO and
DAO as dead - it is no longer being developed. In fact, MSDE is more dead
than DAO, in that there is no longer any logical reason to use it, as SQL
Server Express more than takes the place of it.

SQL Server Express is not MSDE, any more than ADO.Net is ADO, or MSDE is SQL
Server.
--
Darryl Kerkeslager
Feb 19 '06 #4
Darryl Kerkeslager wrote:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

Well, not dead, but renamed, which suggests that any documentation
using the term "MSDE" is out of date, and, perhaps obsolete.


No - it is dead - in the same sense that people have referred to ADO and
DAO as dead - it is no longer being developed. In fact, MSDE is more dead
than DAO, in that there is no longer any logical reason to use it, as SQL
Server Express more than takes the place of it.

SQL Server Express is not MSDE, any more than ADO.Net is ADO, or MSDE is SQL
Server.
--
Darryl Kerkeslager


This is interesting. In spite of it being called Access 12, Microsoft
is really eliminating Access and VBA. SQL Server Express for the data
and .NET for the interface with definitions and reporting in XML.
[cliche alert] It's starting to look like they dumped the RAD baby out
with the bathwater. That is, unless you falsely imagine that the extra
flexibility MS designed into Access 12 reporting will be able to handle
every situation. MS had good reasons for going in these directions so
I'll try not to mourn the death of Access too long. I'll do the best I
can to create a RAD environment without what we once understood Access
to be. [cliche alert] Putting Access' clothes on .NET reminds me of a
certain silk pigskin wallet. [cliche alert] It seems that the reports
of Access' demise were not premature.

James A. Fortune
CD********@FortuneJames.com

Feb 20 '06 #5
"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:mJ******************************@comcast.com:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

Well, not dead, but renamed, which suggests that any
documentation using the term "MSDE" is out of date, and, perhaps
obsolete.


No - it is dead - in the same sense that people have referred to
ADO and DAO as dead - it is no longer being developed. In fact,
MSDE is more dead than DAO, in that there is no longer any logical
reason to use it, as SQL Server Express more than takes the place
of it.

SQL Server Express is not MSDE, any more than ADO.Net is ADO, or
MSDE is SQL Server.


Exactly how is SQL Server Express not MSDE renamed? Isn't it just a
throttled version of SQL Server, just like MSDE?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 20 '06 #6
CD********@FortuneJames.com wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:
Darryl Kerkeslager wrote:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote
>
> Well, not dead, but renamed, which suggests that any
> documentation using the term "MSDE" is out of date, and,
> perhaps obsolete.
No - it is dead - in the same sense that people have referred to
ADO and DAO as dead - it is no longer being developed. In fact,
MSDE is more dead than DAO, in that there is no longer any
logical reason to use it, as SQL Server Express more than takes
the place of it.

SQL Server Express is not MSDE, any more than ADO.Net is ADO, or
MSDE is SQL Server.
--
Darryl Kerkeslager


This is interesting. In spite of it being called Access 12,
Microsoft is really eliminating Access and VBA. SQL Server
Express for the data and .NET for the interface with definitions
and reporting in XML.


Huh? Where in the world are you getting this information? Surely not
from the Access 12 blog on MSDN, which has said nothing of the sort.
[cliche alert] It's starting to look like they dumped the RAD baby
out with the bathwater. . . .
If your major premise is wrong, your minor premise cannot be proven.
. . . That is, unless you falsely imagine that the extra
flexibility MS designed into Access 12 reporting will be able to
handle every situation. . ..
They are keeping the same report designer UI and adding a new Layout
view, which is like an editable print preview. Sounds like a good
thing to me -- use the old methods where they work best, and the new
ones where those are better.

How the report definition is actually stored is really completely
irrelevant to me, as I don't have access to that, in any case,
unless I want to do a SaveAsText (which I never do, unless I'm
trying to recover a corrupted report).
. . . MS had good reasons for going in these directions so
I'll try not to mourn the death of Access too long. . . .
What in the world are you talking about?
. . . I'll do the best I
can to create a RAD environment without what we once understood
Access to be. [cliche alert] Putting Access' clothes on .NET
reminds me of a certain silk pigskin wallet. [cliche alert] It
seems that the reports of Access' demise were not premature.


Are you completely insane? None of the things you are talking about
are going to happen according to the official Access blog on MSDN.

None.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 20 '06 #7
David W. Fenton wrote:
CD********@FortuneJames.com wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:
Darryl Kerkeslager wrote:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote
>
> Well, not dead, but renamed, which suggests that any
> documentation using the term "MSDE" is out of date, and,
> perhaps obsolete.

No - it is dead - in the same sense that people have referred to
ADO and DAO as dead - it is no longer being developed. In fact,
MSDE is more dead than DAO, in that there is no longer any
logical reason to use it, as SQL Server Express more than takes
the place of it.

SQL Server Express is not MSDE, any more than ADO.Net is ADO, or
MSDE is SQL Server.
--
Darryl Kerkeslager
This is interesting. In spite of it being called Access 12,
Microsoft is really eliminating Access and VBA. SQL Server
Express for the data and .NET for the interface with definitions
and reporting in XML.


Huh? Where in the world are you getting this information? Surely not
from the Access 12 blog on MSDN, which has said nothing of the sort.


It's possible that ADO and DAO will be available in Access 12 but SQL
Server Express without VBA definitely seems to be where MS is heading.
I have not seen any indication anywhere that VBA will be able to be
used in Access 12 at all. I may be wrong. If you need to customize
the output before or after it's created you need something like Visual
Studio or FrontPage or something else. XML is not just used as a
storage mechanism. If Access 12 can't create the XML you need, then
VBA is not an option.
[cliche alert] It's starting to look like they dumped the RAD baby
out with the bathwater. . . .


If your major premise is wrong, your minor premise cannot be proven.


That may be so, but VB.NET or C# is quite a bit slower to develop in
than VBA.
. . . That is, unless you falsely imagine that the extra
flexibility MS designed into Access 12 reporting will be able to
handle every situation. . ..


They are keeping the same report designer UI and adding a new Layout
view, which is like an editable print preview. Sounds like a good
thing to me -- use the old methods where they work best, and the new
ones where those are better.


No VBA behind a report. So much for the old methods. If you're happy
with what Access 12 can do natively then things are better with the new
design.

How the report definition is actually stored is really completely
irrelevant to me, as I don't have access to that, in any case,
unless I want to do a SaveAsText (which I never do, unless I'm
trying to recover a corrupted report).
The XML for the report is already in plain text. SaveAsText won't help
corrupted reports. You'll need to start indenting the XML source for
that :-).
. . . MS had good reasons for going in these directions so
I'll try not to mourn the death of Access too long. . . .
What in the world are you talking about?


Everything needed to move toward something that would work for the
internet/intranet world. I was talking about eliminating VBA and the
way mdb files are stored. Those are good things in the long run. I
just need to find something that makes up for the loss of VBA.
. . . I'll do the best I
can to create a RAD environment without what we once understood
Access to be. [cliche alert] Putting Access' clothes on .NET
reminds me of a certain silk pigskin wallet. [cliche alert] It
seems that the reports of Access' demise were not premature.


Are you completely insane? None of the things you are talking about
are going to happen according to the official Access blog on MSDN.

None.


I don't think it's going to be Access anymore. I think it's going to
be SQL Server and .NET with some flexible XML writing thrown in. I
think it's going to be more powerful than before. I think the
development process will be slower. Visual C++ is extremely powerful
but I don't design databases with it. I hope you're correct about
being able to use ADO or DAO like before without resorting to .NET
coding. I don't think that the new flexibility that reports are going
to have is enough to justify calling the new .NET thing Access. Even
custom SQL will have to be part of the .NET code. [mangled cliche
alert] If it looks, sounds and acts like .NET then it is a dog :-).

James A. Fortune
CD********@FortuneJames.com

Feb 20 '06 #8
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

Exactly how is SQL Server Express not MSDE renamed? Isn't it just a
throttled version of SQL Server, just like MSDE?


Scaled down, but not really "throttled" like MSDE was.

MSDE had this "feature" (MSDN):

In summary, the workload governor in the database engine for SQL Server 2000
Desktop Engine (MSDE 2000) and SQL Server 2000 Personal Edition works by
counting active operations. When there are more than eight active operations
at the same time in the same instance of the database engine, the governor
implements a slight wait before each logical read or write to a data file.
For the amount of work typical in databases used by single users or small
workgroups, the cumulative effect of the waits is not noticeable. In systems
that are reading and writing large amounts of data, the cumulative affect of
all the waits slows the performance of the database engine.

Below is the comparison between 2005 SQL Server editions.
http://www.microsoft.com/sql/prodinf...-features.mspx
From http://www.databasejournal.com/featu...e.php/3492296:

Microsoft repeatedly uses the phrases "simple applications", "lightweight,"
and "mobile or web applications" when describing the target uses for SQL
Server Express 2005. However, the generous restrictions of Express make it
an ideal database for many applications. Express is limited to 1 CPU, 1 GB
RAM, and 4 GB Max database size. There is NO workload governor (See July
article SQL Sever 2000 MDSE for a complete description of the workload
governor). Meaning SQL will not slow, or restrict its response times due to
licensing constraints. SQL Server Express can be installed on a machine with
multiple CPUs and RAM in excess of 1 GB, but the database engine will limit
scheduler threads to one, meaning only one CPU will be used. Similarly, the
buffer pool, where data pages are stored, will only use 1 GB of RAM,
regardless of any additional memory available. Enterprise features are not
supported on SQL Express. Missing are Analysis Services, Reporting Services,
DTS, and Notification Services. Aside from these restrictions, the SQL
Server Express database engine is the same one found in the other SQL
products. Triggers, cursors, views, stored procedures, CLR, XML, and TSQL
are all supported the same way they are in any other version of SQL Server.

Note that the 4 GB Max database size does not prevent you from working
around this by using more than one database. Also *not* mentioned, but
pretty important, is that you can *easily* detach and copy mdf files from
one PC to another - someting I guess you can't do so easily with other SQL
Server editions.
--------------------------------

While the differences are not huge between the engines, what is *completely*
different is that SQL Server Express has a GUI in the free Visual Web
Developer Express 2005 and also in the free versions of VB Express 2005, C#
Express 2005, etc.

--
Darryl Kerkeslager
Feb 20 '06 #9
James where in the world did you read that VBA is no longer available with
Access 12? Do you know how ludicrous your statement is?

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
<CD********@FortuneJames.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
David W. Fenton wrote:
CD********@FortuneJames.com wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:
> Darryl Kerkeslager wrote:
>> "David W. Fenton" <XX*******@dfenton.com.invalid> wrote
>> >
>> > Well, not dead, but renamed, which suggests that any
>> > documentation using the term "MSDE" is out of date, and,
>> > perhaps obsolete.
>>
>> No - it is dead - in the same sense that people have referred to
>> ADO and DAO as dead - it is no longer being developed. In fact,
>> MSDE is more dead than DAO, in that there is no longer any
>> logical reason to use it, as SQL Server Express more than takes
>> the place of it.
>>
>> SQL Server Express is not MSDE, any more than ADO.Net is ADO, or
>> MSDE is SQL Server.
>>
>>
>> --
>> Darryl Kerkeslager
>
> This is interesting. In spite of it being called Access 12,
> Microsoft is really eliminating Access and VBA. SQL Server
> Express for the data and .NET for the interface with definitions
> and reporting in XML.


Huh? Where in the world are you getting this information? Surely not
from the Access 12 blog on MSDN, which has said nothing of the sort.


It's possible that ADO and DAO will be available in Access 12 but SQL
Server Express without VBA definitely seems to be where MS is heading.
I have not seen any indication anywhere that VBA will be able to be
used in Access 12 at all. I may be wrong. If you need to customize
the output before or after it's created you need something like Visual
Studio or FrontPage or something else. XML is not just used as a
storage mechanism. If Access 12 can't create the XML you need, then
VBA is not an option.
> [cliche alert] It's starting to look like they dumped the RAD baby
> out with the bathwater. . . .


If your major premise is wrong, your minor premise cannot be proven.


That may be so, but VB.NET or C# is quite a bit slower to develop in
than VBA.
> . . . That is, unless you falsely imagine that the extra
> flexibility MS designed into Access 12 reporting will be able to
> handle every situation. . ..


They are keeping the same report designer UI and adding a new Layout
view, which is like an editable print preview. Sounds like a good
thing to me -- use the old methods where they work best, and the new
ones where those are better.


No VBA behind a report. So much for the old methods. If you're happy
with what Access 12 can do natively then things are better with the new
design.

How the report definition is actually stored is really completely
irrelevant to me, as I don't have access to that, in any case,
unless I want to do a SaveAsText (which I never do, unless I'm
trying to recover a corrupted report).


The XML for the report is already in plain text. SaveAsText won't help
corrupted reports. You'll need to start indenting the XML source for
that :-).
> . . . MS had good reasons for going in these directions so
> I'll try not to mourn the death of Access too long. . . .


What in the world are you talking about?


Everything needed to move toward something that would work for the
internet/intranet world. I was talking about eliminating VBA and the
way mdb files are stored. Those are good things in the long run. I
just need to find something that makes up for the loss of VBA.
> . . . I'll do the best I
> can to create a RAD environment without what we once understood
> Access to be. [cliche alert] Putting Access' clothes on .NET
> reminds me of a certain silk pigskin wallet. [cliche alert] It
> seems that the reports of Access' demise were not premature.


Are you completely insane? None of the things you are talking about
are going to happen according to the official Access blog on MSDN.

None.


I don't think it's going to be Access anymore. I think it's going to
be SQL Server and .NET with some flexible XML writing thrown in. I
think it's going to be more powerful than before. I think the
development process will be slower. Visual C++ is extremely powerful
but I don't design databases with it. I hope you're correct about
being able to use ADO or DAO like before without resorting to .NET
coding. I don't think that the new flexibility that reports are going
to have is enough to justify calling the new .NET thing Access. Even
custom SQL will have to be part of the .NET code. [mangled cliche
alert] If it looks, sounds and acts like .NET then it is a dog :-).

James A. Fortune
CD********@FortuneJames.com

Feb 21 '06 #10
CD********@FortuneJames.com wrote:
It's possible that ADO and DAO will be available in Access 12 but SQL
Server Express without VBA definitely seems to be where MS is heading.
I have not seen any indication anywhere that VBA will be able to be
used in Access 12 at all. I may be wrong.


Yes, you may.

Feb 21 '06 #11
Stephen Lebans wrote:
James where in the world did you read that VBA is no longer available with
Access 12? Do you know how ludicrous your statement is?


Whew. I'm glad it was ludicrous. I thought VBA was history.

Lyle Fairfield wrote:

:Yes you may.

Whew. I'm glad I'm allowed to be wrong every now and then :-).

James A. Fortune

Feb 21 '06 #12
"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:ib********************@comcast.com:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

Exactly how is SQL Server Express not MSDE renamed? Isn't it just
a throttled version of SQL Server, just like MSDE?


Scaled down, but not really "throttled" like MSDE was.


Well, the differences are interesting, but the assertion that the
differences between MSDE and SQL Server Express are like the
differences between ADO and ADO.NET is completely wrong, don't you
think? SQL Server Express is still SQL Server. It responds to the
same commands and serves the same data, it just has slightly
different limitations.

The fact that there is now a separate piece of software that
provides a free GUI is really pretty much irrelevant to a comparison
of MSDE and SQL Server Express, since by acquiring other software
you could have a GUI for administering MSDE, too (though perhaps
you'd have to buy something to get it).

In the end, though, all of this does show that documentation that
refers to MSDE is out of date, and, thus, using that MSDE
documentation to show that ADO is still recommended for current MS
products basically goes out the window.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 21 '06 #13
CD********@FortuneJames.com wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:
David W. Fenton wrote:
CD********@FortuneJames.com wrote in
news:11**********************@g14g2000cwa.googlegr oups.com:
> This is interesting. In spite of it being called Access 12,
> Microsoft is really eliminating Access and VBA. SQL Server
> Express for the data and .NET for the interface with
> definitions and reporting in XML.
Huh? Where in the world are you getting this information? Surely
not from the Access 12 blog on MSDN, which has said nothing of
the sort.


It's possible that ADO and DAO will be available in Access 12. . .


It's not only "possible" but it's what MS is promising. Access 12 is
going to be backwardly compatible. And I can't recall any statements
that it's going to introduce any form of .NET into Access.
. . . but SQL
Server Express without VBA definitely seems to be where MS is
heading. . .
Not for Access. I believe that you are completely misinformed. What
Access 12 is actually going to offer is a new default db engine that
is derived from (and backwardly compatible with) Jet. See:

http://blogs.msdn.com/access/archive...13/480870.aspx
I have not seen any indication anywhere that VBA will be able to
be used in Access 12 at all. . . .
I think you've got it entirely upside-down. I have seen absolutely
no indication anywhere in the voluminous writings from Microsoft
employees about the new Access 12 that indicate an abandonment of
VBA and any significant move to .NET (except for add-ons, i.e., code
that is external to Access).

But, please, show me where on the Access blog that it says VBA is
out and .NET will replace it:

http://blogs.msdn.com/access/
. . . I may be wrong. . . .
I think you are completely mistaken. There are a lot of new features
described in this "what's new" article:

http://blogs.msdn.com/access/archive...07/490113.aspx

But not once is any change to VBA or incorporation of .NET
mentioned. I'd think that would be a major issue if it were happen,
and not something that MS would be completely silent about.

But if you have a link where an authoritative source from MS has
said that VBA is being abandoned in Access in favor of .NET, then,
please, provide the documentaiton for it.
. . . If you need to customize
the output before or after it's created you need something like
Visual Studio or FrontPage or something else. XML is not just
used as a storage mechanism. If Access 12 can't create the XML
you need, then VBA is not an option.
This is all so much fantasy. It has no basis in any reality that
Microsoft has described for Access 12.
> [cliche alert] It's starting to look like they dumped the RAD
> baby out with the bathwater. . . .


If your major premise is wrong, your minor premise cannot be
proven.


That may be so, but VB.NET or C# is quite a bit slower to develop
in than VBA.


Those are irrelevant, as THEY AREN'T GOING TO BE INCORPORATED INTO
ACCESS 12. That's what I meant by "major premise" -- the assertion
about VBA being dropped is simply WRONG, thus any comments about
relative RAD capabilities and speed are just nonsensical.
> . . . That is, unless you falsely imagine that the extra
> flexibility MS designed into Access 12 reporting will be able
> to handle every situation. . ..


They are keeping the same report designer UI and adding a new
Layout view, which is like an editable print preview. Sounds like
a good thing to me -- use the old methods where they work best,
and the new ones where those are better.


No VBA behind a report. . . .


Where is this stated? Nowhere, so far as I can see. The Access 12
blog recently had a post with extensive discussion of the new report
designer:

http://blogs.msdn.com/access/archive...13/531116.aspx

Nowhere in there does it say anything about there being no VBA code
behind the report. Of course, it doesn't relaly discuss coding,
because the focus of the post is on the end-user aspects of Access,
rather than the developer aspects.

Indeed, statements like this:

Easier to extend Access apps with Visual Studio – despite our
best efforts, Access will not offer all the power of Visual
Studio, and for some tasks developers will want to use VS. We
believe a key part of the strategy needs to be to make it easy
for VS developers to extend Access apps without having to
re-write them. Office 12 does this to some extent (e.g.
workflows written in the SharePoint Designer can be easily
edited in VS), but there is clearly more to do here.

from this post on "Access's Commitment to Developers":

http://blogs.msdn.com/access/archive...30/498466.aspx

You'd think that if what you say is true, this quotation that shows
substantial distancing between Access and VS would simply make no
sense.
. . . So much for the old methods. If you're happy
with what Access 12 can do natively then things are better with
the new design.
There is no evidence anywhere that Access 12 is going to remove the
old ways of doing things. Indeed, in the discussion of the new
layout view in the report designer, the point is made quite clearly
that the old design view is still going to be available because a
lot of tasks remain that will be better accomplished in that view
than in layout view.

The completely absence of any mention of the elimination of VBA
suggests to me that it's going to be there. And the repeated
insistence on backward compatibility suggests to me that you are
wholly mistaken in your assertions about about VBA and .NET in
Access 12.
How the report definition is actually stored is really completely
irrelevant to me, as I don't have access to that, in any case,
unless I want to do a SaveAsText (which I never do, unless I'm
trying to recover a corrupted report).


The XML for the report is already in plain text. SaveAsText won't
help corrupted reports. You'll need to start indenting the XML
source for that :-).


Non sequitur.

The point is that if the UI for designing and using the report, and
the coding environment remain the same, a change in the storage
format is completely irrelevant for 99.99% of Access programmers and
end users. It's only the small number of cases where you've built
something that depends on the undocumented SaveAsText that you'd run
into a problem if the storage format has changed.

I have seen nothing in the information distributed about Access 12
that says you'll be designing your reports by manipulating XML
directly. If you have information from MS that says this is so,
then, please, provide a citation of it.
> . . . MS had good reasons for going in these directions so
> I'll try not to mourn the death of Access too long. . . .


What in the world are you talking about?


Everything needed to move toward something that would work for the
internet/intranet world. I was talking about eliminating VBA and
the way mdb files are stored. Those are good things in the long
run. I just need to find something that makes up for the loss of
VBA.


THERE IS NO LOSS OF VBA.

THERE IS NO LOSS OF THE MDB FILE FORMAT.

THERE IS NO MOVE TOWARDS DIRECTLY MANIPULATING XML FOR REPORT
DESIGN.

You are simply wrong on all counts about what is happening with the
design of Access 12.

I've seen for years many people speculating that what you describe
would happen with the post-2003 version of Access, but it isn't
happening after all. Your assertions seem to me to be derived from
all the baseless speculation from people outside Microsoft and
outside the Access development team.

My information is based on information direct from one of the leads
of the Access development team.
> . . . I'll do the best I
> can to create a RAD environment without what we once understood
> Access to be. [cliche alert] Putting Access' clothes on .NET
> reminds me of a certain silk pigskin wallet. [cliche alert] It
> seems that the reports of Access' demise were not premature.


Are you completely insane? None of the things you are talking
about are going to happen according to the official Access blog
on MSDN.

None.


I don't think it's going to be Access anymore. . . .


THe key words there appear to me to be "I think."

But you have absolutely no factual basis for making these claims.
. . . I think it's going
to be SQL Server and .NET with some flexible XML writing thrown
in. . . .
Well, then you're just WRONG. It's going to be the new Access db
engine (which is derived from Jet and backwardly compatible with
Jet) with VBA and no required XML manipulation.
. . . I think it's going to be more powerful than before. I think
the development process will be slower. . . .
So far as I can see, we already have what you're describing by
simply using the existing .NET development tools. There would be no
utility whatsoever in making Access like those tools, because
Microsoft would then have two products that are nearly identical in
functionality.

Secondly, such a set of tools would not serve the end-user market at
all. It's quite clear from the posts on the Access blog that the
Access team is putting a huge amount of effort into enhancing
Access's user-friendliness for non-programmers. That move is in
direct contradition of all your assertions about the loss of RAD,
since the RAD features in Access come directly out of the end-user
ease-of-use features.
. . . Visual C++ is extremely
powerful but I don't design databases with it. I hope you're
correct about being able to use ADO or DAO like before without
resorting to .NET coding. . . .
I don't know (or care) about ADO, but Jet is not going away. It is,
in fact, getting a new lease on life, with significant new
development resources going into it. Yes, it will be a different
version of Jet with different capabilities, but that's a *good*
thing, in my opinion.

Now, I'm not wholly pleased with all aspects of the direction of
Access 12. For instance, it's quite clear that Jet replication is
going to be deprecated in favor of SharePoint services. What that
means is that those who want data shared at multiple sites are going
to have to add a server to the mix, and spend extra money for server
software and infrastructure in addition to the development costs
involved, whereas with Jet replication, there was no need for
additional servers or software (though development costs are
significant).

I'm not thrilled with the SharePoint integration in general (not
just with regard to replication), since I just don't see the value.
I don't understand the concepts behind it (which the Access 12 blog
seems to me to treat as something everybody should already know
about) and I don't see any value in it for my clients. It looks like
another example of enterprise-friendly design being stovepiped onto
the small business user. Microsoft Outlook's connection to Exchange
Server is a past example of this, where the software product was
basically pretty much useless without the back end server in place
-- it promised things it couldn't deliver without introducing a very
difficult to maintain server into your network (Exchange 2003 is
much easier to administer than previous versions, but it's still a
bitch compared to not having to maintain a separate server).

Perhaps I'm wrong about this. Perhaps SharePoint services can be run
on a workstation, peer-to-peer, and perhaps they are easy to
administer. I don't know. But I still don't understand what needs
they satisfy -- I have no clients who are crying out for
collaborative document sharing. None.

So, I don't see that the effort going into making Access
SharePoint-friendly is going to help any of my clients at all. My
best hope is that it won't promise things (like shared calendars in
Outlook) that can't be delivered without the server, and that the
features necessary to support it won't make the product without it
more difficult or more confusing to use.
. . . I don't think that the new flexibility
that reports are going to have. . .
You mean "layout view" or are you talking about your imaginary XML
editing of reports?
. . . is enough to justify calling the
new .NET thing Access. . . .
There is no such thing as a product called "Access" with .NET
incorporated into it.
. . . Even custom SQL will have to be part of
the .NET code. [mangled cliche alert] If it looks, sounds and
acts like .NET then it is a dog :-).


You are completely in fantasy land. There is no support anywhere in
the materials describing Access 12 that supports any of your
assertions about what Access 12 is going to be.

None.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 21 '06 #14
CD********@FortuneJames.com wrote in
news:11**********************@o13g2000cwo.googlegr oups.com:
Stephen Lebans wrote:
James where in the world did you read that VBA is no longer
available with Access 12? Do you know how ludicrous your
statement is?


Whew. I'm glad it was ludicrous. I thought VBA was history.


Do you realize what a dis-service you've done to this newsgroup by
posting the things you've posted here? You've created a set of
rumors that someone searching Google Groups may encounter, which may
end up as misinformation that propagates far beyond this particular
thread.

If you didn't have any actual proof for any of your assertions, then
you shouldn't have made such ridiculous statements.

I'm beginning to recall now why I had killfiled your previous email
address. I haven't yet decided if I'll be plonking this one, too.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 21 '06 #15
David W. Fenton wrote:
I'm beginning to recall now why I had killfiled your previous email
address. I haven't yet decided if I'll be plonking this one, too.


Please do. You're too uptight and I don't want to stress you out.

James A. Fortune
CD********@FortuneJames.com

Feb 22 '06 #16
Hi
I have a question about how to create an index using code in MS Access
2003 after the code has run a make table query in the same database. I
would Also like to adapt it so that a table I created in another
database using a Make table query has an index created next time I open
the other database.

I think I would use the ADO append methode with the index collection but
not clear on how to do the code.

I assume you would identify the table collection and specific table to
work on then append the index but can not find any examples.

Any assistance would be appreciated.

Greg
Mar 3 '06 #17
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Easiest way is to use a DDL command.

CREATE [UNIQUE] INDEX <index name> ON <table name> (<column list>)

E.g.:

CREATE INDEX idx_SalesDate ON Orders (sales_date)

Use an ADO connection's Execute method to run the command.

See the Access Help articles under "SQL Reference."
--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBRAisbIechKqOuFEgEQJjdQCg6JG1g14gGBLze6zkK8Ongf TwdbQAmwdD
mxNHaNGlFJw4lZA/Y7416cUi
=6WJu
-----END PGP SIGNATURE-----
Greg wrote:
Hi
I have a question about how to create an index using code in MS Access
2003 after the code has run a make table query in the same database. I
would Also like to adapt it so that a table I created in another
database using a Make table query has an index created next time I open
the other database.

I think I would use the ADO append methode with the index collection but
not clear on how to do the code.

I assume you would identify the table collection and specific table to
work on then append the index but can not find any examples.

Mar 3 '06 #18
MGFoster
Thanks for the quick response I will try it out and see how I go
Regards

Greg

MGFoster wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Easiest way is to use a DDL command.

CREATE [UNIQUE] INDEX <index name> ON <table name> (<column list>)

E.g.:

CREATE INDEX idx_SalesDate ON Orders (sales_date)

Use an ADO connection's Execute method to run the command.

See the Access Help articles under "SQL Reference."

Mar 3 '06 #19
MGFoster wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Easiest way is to use a DDL command.

CREATE [UNIQUE] INDEX <index name> ON <table name> (<column list>)


I agree, but I also want to point out that DAO tabledefs have a
CreateIndex method and that there is a Collection of Index objects.

James A. Fortune
CD********@FortuneJames.com

Our business is to establish peace and order on a satisfactory basis,
start the new government, and then leave the Island; the Cuban
Government taking the reins into its own hands; tho of course it might
be advisable for some little time that some of our troops should stay
in the Islands to steady things.
--- Theodore Roosevelt 1907

Mar 3 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Christian Tismer | last post by:
Dear Former Stackless Users, I have to use this list to announce something really bad to you, since all the Stackless lists are defunct: The Stackless project is finally dead, now and forever....
0
by: Cram TeXeD | last post by:
Hello people ! Just a question : I'm working on LDAP directories, and I would use DSML, but I have some doubts about it. Is it dead ? Last minutes from OASIS committy were around 2002, and except...
7
by: Mark Johnson | last post by:
I see less than 20 or so posts a day, here. Is this, essentially, a dead ng? And what ng do people use, instead?
35
by: Geronimo W. Christ Esq | last post by:
Are there any scripts or tools out there that could look recursively through a group of C/C++ source files, and allow unreferenced function calls or values to be easily identified ? LXR is handy...
8
by: Holger Fleckenstein | last post by:
Hi, I have a problem with a server socket (winsock2.h). I do all standard stuff like listen(), accept() and so on, which all works fine. I only want one client to be able to connect at a time and...
3
by: Sloan.Kohler | last post by:
Is Jython development dead or has it just seemed that way for over a year?. The jython.org website has a recent new appearance (but no new content) and there is some message traffic on the...
4
by: jaysome | last post by:
/* Does main1() have dead code that can never achieve 100% decision coverage? And is main2() a valid way of fixing it so that there is no dead code and the assert() never fires off and 100%...
0
by: =?Utf-8?B?S2luZXRpYyBKdW1wIEFwcGxpZmUgZm9yIC5ORVQg | last post by:
Dead-end for Microsoft ? Many people say Microsoft has reached a dead-end with all its buggy products. But why do you think it’s products are still out there in the market? Why do you think it...
4
by: bukzor | last post by:
Does anyone have a pythonic way to check if a process is dead, given the pid? This is the function I'm using is quite OS dependent. A good candidate might be "try: kill(pid)", since it throws an...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.