|
|
I have inherited an access database that was converted from 2000 to 2007. The
tables were then uploaded to SQL and linked. Can the .mdb file be converted
to an .adp?
|
|
Yes.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Dave" <Dave[ at ]discussions.microsoft.com> wrote in message
news:C60AE7C9-92A6-4CA8-8947-2052E7967D56[ at ]microsoft.com...
[Quoted Text] >I have inherited an access database that was converted from 2000 to 2007.
>The
> tables were then uploaded to SQL and linked. Can the .mdb file be
> converted
> to an .adp?
|
|
Well I can find nothing explicit in the MS documentation on how to do this.
so it looks like you would create an ADP project, link to the SQL database
and then import the forms and reports from the converted Access .mdb file,
correct?
Dave
"Sylvain Lafontaine" wrote:
[Quoted Text] > Yes.
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
>
> "Dave" <Dave[ at ]discussions.microsoft.com> wrote in message
> news:C60AE7C9-92A6-4CA8-8947-2052E7967D56[ at ]microsoft.com...
> >I have inherited an access database that was converted from 2000 to 2007.
> >The
> > tables were then uploaded to SQL and linked. Can the .mdb file be
> > converted
> > to an .adp?
>
>
>
|
|
Yes, and then fixup the things that are different in an adp. If you have SQL
strings, for example, SQL Server's sql syntax has some differences from
Access' sql syntax. Since the SQL would now be executing on the server, you
can't use any Access or VBA functions in the sql.
"Dave" <Dave[ at ]discussions.microsoft.com> wrote in message
news:86BA5D6E-19FA-43B6-B4A8-6C2FC642F560[ at ]microsoft.com...
[Quoted Text] > Well I can find nothing explicit in the MS documentation on how to do
> this.
> so it looks like you would create an ADP project, link to the SQL database
> and then import the forms and reports from the converted Access .mdb file,
> correct?
>
> Dave
>
> "Sylvain Lafontaine" wrote:
>
>> Yes.
>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>> "Dave" <Dave[ at ]discussions.microsoft.com> wrote in message
>> news:C60AE7C9-92A6-4CA8-8947-2052E7967D56[ at ]microsoft.com...
>> >I have inherited an access database that was converted from 2000 to
>> >2007.
>> >The
>> > tables were then uploaded to SQL and linked. Can the .mdb file be
>> > converted to an .adp?
|
|
Like Paul has said, there is nothing magical with an ADP project: you can
take any form from a MDB database file and copy&paste or import them into an
ADP project. It's only after the forms has been copied (or imported) into
the ADP project that the fun begins.
If somes of your queries in the Querydef collections are simple enough, the
upsizing wizard or the Migration Assistant (SSMA-A) will be able to
translate them into SQL' views, stored procedures (SP) or functions (UDF);
saving you some manipulations. I think that the SSMA-A has a preference for
UDFs but personally, I prefer to use SP. However, both possibilities are
OK.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Paul Shapiro" <paul[ at ]hideme.broadwayData.com> wrote in message
news:ujF1U2oRJHA.1164[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > Yes, and then fixup the things that are different in an adp. If you have
> SQL strings, for example, SQL Server's sql syntax has some differences
> from Access' sql syntax. Since the SQL would now be executing on the
> server, you can't use any Access or VBA functions in the sql.
>
> "Dave" <Dave[ at ]discussions.microsoft.com> wrote in message
> news:86BA5D6E-19FA-43B6-B4A8-6C2FC642F560[ at ]microsoft.com...
>> Well I can find nothing explicit in the MS documentation on how to do
>> this.
>> so it looks like you would create an ADP project, link to the SQL
>> database
>> and then import the forms and reports from the converted Access .mdb
>> file,
>> correct?
>>
>> Dave
>>
>> "Sylvain Lafontaine" wrote:
>>
>>> Yes.
>>>
>>> --
>>> Sylvain Lafontaine, ing.
>>> MVP - Technologies Virtual-PC
>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>
>>>
>>> "Dave" <Dave[ at ]discussions.microsoft.com> wrote in message
>>> news:C60AE7C9-92A6-4CA8-8947-2052E7967D56[ at ]microsoft.com...
>>> >I have inherited an access database that was converted from 2000 to
>>> >2007.
>>> >The
>>> > tables were then uploaded to SQL and linked. Can the .mdb file be
>>> > converted to an .adp?
>
|
|
Paul and Sylvain - thank you for the information. It has been very helpful.
"Sylvain Lafontaine" wrote:
[Quoted Text] > Like Paul has said, there is nothing magical with an ADP project: you can > take any form from a MDB database file and copy&paste or import them into an > ADP project. It's only after the forms has been copied (or imported) into > the ADP project that the fun begins. > > If somes of your queries in the Querydef collections are simple enough, the > upsizing wizard or the Migration Assistant (SSMA-A) will be able to > translate them into SQL' views, stored procedures (SP) or functions (UDF); > saving you some manipulations. I think that the SSMA-A has a preference for > UDFs but personally, I prefer to use SP. However, both possibilities are > OK. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > > "Paul Shapiro" <paul[ at ]hideme.broadwayData.com> wrote in message > news:ujF1U2oRJHA.1164[ at ]TK2MSFTNGP03.phx.gbl... > > Yes, and then fixup the things that are different in an adp. If you have > > SQL strings, for example, SQL Server's sql syntax has some differences > > from Access' sql syntax. Since the SQL would now be executing on the > > server, you can't use any Access or VBA functions in the sql. > > > > "Dave" <Dave[ at ]discussions.microsoft.com> wrote in message > > news:86BA5D6E-19FA-43B6-B4A8-6C2FC642F560[ at ]microsoft.com... > >> Well I can find nothing explicit in the MS documentation on how to do > >> this. > >> so it looks like you would create an ADP project, link to the SQL > >> database > >> and then import the forms and reports from the converted Access .mdb > >> file, > >> correct? > >> > >> Dave > >> > >> "Sylvain Lafontaine" wrote: > >> > >>> Yes. > >>> > >>> -- > >>> Sylvain Lafontaine, ing. > >>> MVP - Technologies Virtual-PC > >>> E-mail: sylvain aei ca (fill the blanks, no spam please) > >>> > >>> > >>> "Dave" <Dave[ at ]discussions.microsoft.com> wrote in message > >>> news:C60AE7C9-92A6-4CA8-8947-2052E7967D56[ at ]microsoft.com... > >>> >I have inherited an access database that was converted from 2000 to > >>> >2007. > >>> >The > >>> > tables were then uploaded to SQL and linked. Can the .mdb file be > >>> > converted to an .adp? > > > > > |
|
interesting.
yes, most poeple in the real world avoid UDF like the plague- until
SQL 2005 when SchemaBinding clause can increase performance 500%
On Nov 14, 12:07 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > Like Paul has said, there is nothing magical with an ADP project: you can > take any form from a MDB database file and copy&paste or import them into an > ADP project. It's only after the forms has been copied (or imported) into > the ADP project that the fun begins. > > If somes of your queries in the Querydef collections are simple enough, the > upsizing wizard or the Migration Assistant (SSMA-A) will be able to > translate them into SQL' views, stored procedures (SP) or functions (UDF); > saving you some manipulations. I think that the SSMA-A has a preference for > UDFs but personally, I prefer to use SP. However, both possibilities are > OK. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > "Paul Shapiro" <p...[ at ]hideme.broadwayData.com> wrote in message > > news:ujF1U2oRJHA.1164[ at ]TK2MSFTNGP03.phx.gbl... > > > > > Yes, and then fixup the things that are different in an adp. If you have > > SQL strings, for example, SQL Server's sql syntax has some differences > > from Access' sql syntax. Since the SQL would now be executing on the > > server, you can't use any Access or VBA functions in the sql. > > > "Dave" <D...[ at ]discussions.microsoft.com> wrote in message > >news:86BA5D6E-19FA-43B6-B4A8-6C2FC642F560[ at ]microsoft.com... > >> Well I can find nothing explicit in the MS documentation on how to do > >> this. > >> so it looks like you would create an ADP project, link to the SQL > >> database > >> and then import the forms and reports from the converted Access .mdb > >> file, > >> correct? > > >> Dave > > >> "Sylvain Lafontaine" wrote: > > >>> Yes. > > >>> -- > >>> Sylvain Lafontaine, ing. > >>> MVP - Technologies Virtual-PC > >>> E-mail: sylvain aei ca (fill the blanks, no spam please) > > >>> "Dave" <D...[ at ]discussions.microsoft.com> wrote in message > >>>news:C60AE7C9-92A6-4CA8-8947-2052E7967D56[ at ]microsoft.com... > >>> >I have inherited an access database that was converted from 2000 to > >>> >2007. > >>> >The > >>> > tables were then uploaded to SQL and linked. Can the .mdb file be > >>> > converted to an .adp?- Hide quoted text - > > - Show quoted text -
|
|
|
|
I don't suppose you'd care to venture an opinion as to WHY Microsoft makes
that recommendation, would you? Other than easier local caching of remote
data (which is still possible using an ADP, albeit much more unwieldy),
there seemed to be very little to recommend linked tables over an ADP last
time I looked.
Rob
Mary Chipman [MSFT] wrote:
[Quoted Text]
|
|
Basically it boils down flexibility, security and managing server-side
objects. With a linked table app, users can create their own
queries/views and they are saved on the client. Allowing users to
create/save their own views and stored procedures can create
management problems with clutter, assigning permissions, etc. Although
you can work around not caching server-side objects in ADPs by using
XML (etc), it takes a lot more work. That being said, many people find
ADPs tremendously useful for certain scenarios. As with any database
application, there is no "one size fits all" and Microsoft certainly
does not discourage ADPs for those who have weighed the alternatives
and find that ADPs best suit a particular business need.
--Mary
On Sun, 16 Nov 2008 10:20:01 -0800, "Mary Chipman [MSFT]"
<mchip[ at ]online.microsoft.com> wrote:
[Quoted Text]
|
|
It's hard to believe that it's you, Mary C., who have just wrote that.
However, now that you have wrote it, it will remains on the Internet
forever.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Mary Chipman [MSFT]" <mchip[ at ]online.microsoft.com> wrote in message
news:5ff5i459asr0jo9hpvaufuuqs5uj6gsqh5[ at ]4ax.com...
[Quoted Text] > Basically it boils down flexibility, security and managing server-side > objects. With a linked table app, users can create their own > queries/views and they are saved on the client. Allowing users to > create/save their own views and stored procedures can create > management problems with clutter, assigning permissions, etc. Although > you can work around not caching server-side objects in ADPs by using > XML (etc), it takes a lot more work. That being said, many people find > ADPs tremendously useful for certain scenarios. As with any database > application, there is no "one size fits all" and Microsoft certainly > does not discourage ADPs for those who have weighed the alternatives > and find that ADPs best suit a particular business need. > > --Mary > > On Sun, 16 Nov 2008 10:20:01 -0800, "Mary Chipman [MSFT]" > <mchip[ at ]online.microsoft.com> wrote: > >>Is there a particular reason that you feel you need to use ADP's >>instead of linked tables? For new projects using Access-to-SQL Server, >>Microsoft recommends using ODBC links, although of course ADP's are >>also supported. Here are some other resources to help you decide which >>approach best suits your business needs. >> >>--Mary >> >>TechEd Online Panel (video): >>Go to http://msdn.microsoft.com/en-us/events/teched/cc676818.aspx and >>search for: >>"Are we there yet? Successfully navigating the bumpy road from Access >>to SQL Server" >> >>Microsoft Access or SQL Server 2005: What's Right in Your >>Organization? >> http://www.microsoft.com/sql/solutions/migration/access/sql-or-access.mspx>> >>Optimizing Microsoft Office Access Applications Linked to SQL Server >> http://msdn.microsoft.com/en-us/library/bb188204.aspx>> >>What are the main differences between Access and SQL Server? >> http://sqlserver2000.databases.aspfaq.com/what-are-the-main-differences-between-access-and-sql-server.html>> >>"The Best of Both Worlds--Access MDBs and SQL Server" >> http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp>> >>SQL Server Migration Assistant for Access (SSMA for Access) >> http://www.microsoft.com/sql/solutions/migration/access/default.mspx>> >>FMS Upsizing Center >> http://www.fmsinc.com/Consulting/sqlupsizedocs.aspx>> >>Microsoft Access Developer's Guide to SQL Server >> http://www.amazon.com/dp/0672319446>> >> >>On Fri, 14 Nov 2008 08:06:01 -0800, Dave >><Dave[ at ]discussions.microsoft.com> wrote: >> >>>I have inherited an access database that was converted from 2000 to 2007. >>>The >>>tables were then uploaded to SQL and linked. Can the .mdb file be >>>converted >>>to an .adp?
|
|
Robert Morley <rmorley[ at ]N0.Freak1n.sparn.magma.ca> wrote in
news:OXPHSmGSJHA.4372[ at ]TK2MSFTNGP04.phx.gbl:
[Quoted Text] > I don't suppose you'd care to venture an opinion as to WHY
> Microsoft makes that recommendation, would you? Other than easier
> local caching of remote data (which is still possible using an
> ADP, albeit much more unwieldy), there seemed to be very little to
> recommend linked tables over an ADP last time I looked.
Here's one statement by MS (under the header "Access Data Projects
(ADPs)"):
http://technet.microsoft.com/en-us/library/cc178973.aspx
Basically, it seems to me that MS realized that the effort to avoid
using Jet was cutting off their nose to spite their face, in that
whatever slowdowns Jet introduces (all of which can be worked
around) it is incredibly flexible in terms of working with multiple
data sources in different formats. The effort to eliminate the Jet
layer resulted in the creation of another layer, and the end result
is that they were back where the started from in terms of
performance while also having sacrificed the amazing features of Jet
that had been developed over the last 15 years.
MS's current policy is that MDB->ODBC->SQL Server is preferable to
the ADP. That's the official statement (though you'll find lots of
older MS documentation that still trumpets the ADP as the next best
thing until the Second Coming).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
I'm not sure what your remarks mean, exactly. I've *always* been a
proponent of creating solutions that meet business needs, not the
other way around. Although I have in the past made many remarks to the
effect that I thought ADPs are a dead-end technology, that is strictly
my personal opinion. Many people have invested time and money in ADP
solutions, and Microsoft is committed to continuing to support them
while gently nudging new developers in the ODBC-linked table direction
for new Access-SQL apps. Hopefully the links to the whitepapers that
thoroughly explain the alternatives will achieve greater immortality
on the internet than my ramblings :)
--Mary
On Tue, 18 Nov 2008 10:55:12 -0500, "Sylvain Lafontaine" <sylvain aei
ca (fill the blanks, no spam please)> wrote:
[Quoted Text] >It's hard to believe that it's you, Mary C., who have just wrote that.
>However, now that you have wrote it, it will remains on the Internet
>forever.
|
|
Oh, everyone here agree that ADP is a dead technology; doesn't take a big
brain to figure that but it's not because ADP is inferior to ODBC linked
tables but simply because MS has took the decision to put practically all
the money toward developping .NET technologies instead of Access. Unless
you're developping a database for storing the kitchen's recipes of your
great, great, grand-mother or the friday night's hockey pool of your local
pub, the gentle push that you're talking about is not toward ODBC linked
tables but toward .NET. In MS's opinion, Access is geared toward usage, not
development. This is why there is no Access certification at the present
time. It's hard to believe that MS itself is taking Access seriously when
there is not even any certification for it.
In your previous post, you have said the following statement: « Basically it
boils down flexibility, security and managing server-side objects. ... ».
Well, then, first, we'll take a look at the word "flexibility". If ODBC
linked tables are so flexible, can you explain to me why it's impossible to
make any little complex statements without having JET saying that the
expression is too complexe, to heavy on ressources, crashing or - in the
best case scenario - see the performance dropping faster than a rock in free
fall? Why is it that in 2008, something as simple as the following
statement:
SELECT T1.*, T2.*
FROM T1 LEFT JOIN T2 ON (T1.Id1 = T2.Id2 and T2.Id2 = 10)
make Access 2003 (didn't took the time to check for other versions) crash if
T1 and T2 are ODBC linked tables (and that it will also crash for a lot of
other simple constructs involving outer joins, subqueries and union
queries).
Make Access capable of doing some little complexe statements against ODBC
linked tables without crashing a regularly as crash test dummy and we could
talk about the technical capabilities of JET's ODBC linked tables. Make the
result of passthrough queries read/write instead of read only and also make
them available as record source for subreports and subforms for continuous
forms and maybe that some people dealing with real enterprise databases will
start looking at this stuff as potentially useful.
And while you're on it, take also the time of solving your case-sensitivity
and collation problems. The fact that in 2008, JET's queries against ODBC
linked tables are still not offering full support for Unicode is practically
unbelievable.
Second, you have wrote the word "security". So you really think that OBDC
linked tables are anything but unsecure? If someone were to store something
confidential like your credit card numbers, you would put your faith on an
ODBC linked table?
Question from the client: - We have a safe but we have some concerns about
the safekeeping of the key because we are keeping under the rug.
Solution from MS: no problem, we will remove it from under the mat and put
it in plain sight on a table nearby. This way, not only you're sure that
anyone around will see it but you're also sure that a thief won't hurt his
back by bending down to take it.
Client: - Great! But what happens if they are two or more thieves?
MS: - Maybe we could put a machine for duplicating keys nearby?
Client: - OK, but make sure that the user's manual is clear and easy to
follow and don't forget the blanks!
Finally, you have made a mention about the difficulty of managing
server-side objects. Great, the next time that a secretary will call me for
a request for a new set of data, I tell her that she'll have to look herself
at the database's schema and make her own set of queries. This is for
reading. Now, for writing, I wonder how many hours it will take before the
database become corrupted when the users will start making their very own
updating statements.
Your notions of security and centralized management of database objects
could be applied to a list of kitchen's recipes but I don't see how anyone
would use those for an enterprise level database or any other serious
business model.
You're totally right when you said that ADPs have their share of problems.
However, I'm afraid that the ADP's set of problem is only a very small
subset of the whole collection held by JET's ODBC linked tables and
passthrough queries. It's also true that MS is actually pushing people out
of ADP but what they are pushed toward is - how could I say that politely -
"questionable".
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Mary Chipman [MSFT]" <mchip[ at ]online.microsoft.com> wrote in message
news:4fb8i45u0c19iqqq194ak23eqisvqjluoc[ at ]4ax.com...
[Quoted Text] > I'm not sure what your remarks mean, exactly. I've *always* been a
> proponent of creating solutions that meet business needs, not the
> other way around. Although I have in the past made many remarks to the
> effect that I thought ADPs are a dead-end technology, that is strictly
> my personal opinion. Many people have invested time and money in ADP
> solutions, and Microsoft is committed to continuing to support them
> while gently nudging new developers in the ODBC-linked table direction
> for new Access-SQL apps. Hopefully the links to the whitepapers that
> thoroughly explain the alternatives will achieve greater immortality
> on the internet than my ramblings :)
>
> --Mary
>
> On Tue, 18 Nov 2008 10:55:12 -0500, "Sylvain Lafontaine" <sylvain aei
> ca (fill the blanks, no spam please)> wrote:
>
>>It's hard to believe that it's you, Mary C., who have just wrote that.
>>However, now that you have wrote it, it will remains on the Internet
>>forever.
|
|
You raise many valid points. I have always publicly and privately
maintained that Microsoft wrongly neglected Access developers, but
unfortunately I'm pretty far down the food chain, so I'm pretty much
ignored every time I make that case :)
If you want security, you must ALWAYS implement it on the data source,
in this case Windows/SQL Server. Nobody ever maintained that you could
secure an application through Access or the ODBC API. In the case of
an Access-SQL app, that means using integrated security, granting EXEC
perms on stored procedures and denying all direct access to tables
while creating an "unbound" front-end that passes stored procedure
parameters through VBA/pass-through queries. The linked table approach
is good here because you can fetch read-only data and cache it on the
client, reducing network/server load. Of course, you have to handle
concurrency yourself, opening another can of worms. An ADP is harder
to implement as "unbound", not easier.
That being said, there will always be tradeoffs between security and
flexibility. If you want the secretary to create data objects, then
you're not going to have a secure app no matter which approach you
choose.
The other point on which we concur is that there isn't enough
help/guidance coming from Microsoft for Access developers trying to
make the decision whether to use ADPs or linked tables for their SQLS
apps. As I said before, every application is unique, and people have
different business requirements. So I've taken to posting this list of
resources which will help people decide what works for them. If I've
missed any that you think will help, please let me know and i'll add
them to the list.-- Mary
TechEd Online Panel (video):
Go to http://msdn.microsoft.com/en-us/events/teched/cc676818.aspx and
search for:
"Are we there yet? Successfully navigating the bumpy road from Access
to SQL Server"
Microsoft Access or SQL Server 2005: What's Right in Your
Organization?
http://www.microsoft.com/sql/solutions/migration/access/sql-or-access.mspx
Optimizing Microsoft Office Access Applications Linked to SQL Server
http://msdn.microsoft.com/en-us/library/bb188204.aspx
What are the main differences between Access and SQL Server?
http://sqlserver2000.databases.aspfaq.com/what-are-the-main-differences-between-access-and-sql-server.html
"The Best of Both Worlds--Access MDBs and SQL Server"
http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp
SQL Server Migration Assistant for Access (SSMA for Access)
http://www.microsoft.com/sql/solutions/migration/access/default.mspx
FMS Upsizing Center
http://www.fmsinc.com/Consulting/sqlupsizedocs.aspx
Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/dp/0672319446
On Wed, 19 Nov 2008 12:35:25 -0500, "Sylvain Lafontaine" <sylvain aei
ca (fill the blanks, no spam please)> wrote:
[Quoted Text] >Oh, everyone here agree that ADP is a dead technology; doesn't take a big
>brain to figure that but it's not because ADP is inferior to ODBC linked
>tables but simply because MS has took the decision to put practically all
>the money toward developping .NET technologies instead of Access. Unless
>you're developping a database for storing the kitchen's recipes of your
>great, great, grand-mother or the friday night's hockey pool of your local
>pub, the gentle push that you're talking about is not toward ODBC linked
>tables but toward .NET. In MS's opinion, Access is geared toward usage, not
>development. This is why there is no Access certification at the present
>time. It's hard to believe that MS itself is taking Access seriously when
>there is not even any certification for it.
>
>In your previous post, you have said the following statement: « Basically it
>boils down flexibility, security and managing server-side objects. ... ».
>Well, then, first, we'll take a look at the word "flexibility". If ODBC
>linked tables are so flexible, can you explain to me why it's impossible to
>make any little complex statements without having JET saying that the
>expression is too complexe, to heavy on ressources, crashing or - in the
>best case scenario - see the performance dropping faster than a rock in free
>fall? Why is it that in 2008, something as simple as the following
>statement:
>
>SELECT T1.*, T2.*
>FROM T1 LEFT JOIN T2 ON (T1.Id1 = T2.Id2 and T2.Id2 = 10)
>
>make Access 2003 (didn't took the time to check for other versions) crash if
>T1 and T2 are ODBC linked tables (and that it will also crash for a lot of
>other simple constructs involving outer joins, subqueries and union
>queries).
>
>Make Access capable of doing some little complexe statements against ODBC
>linked tables without crashing a regularly as crash test dummy and we could
>talk about the technical capabilities of JET's ODBC linked tables. Make the
>result of passthrough queries read/write instead of read only and also make
>them available as record source for subreports and subforms for continuous
>forms and maybe that some people dealing with real enterprise databases will
>start looking at this stuff as potentially useful.
>
>And while you're on it, take also the time of solving your case-sensitivity
>and collation problems. The fact that in 2008, JET's queries against ODBC
>linked tables are still not offering full support for Unicode is practically
>unbelievable.
>
>Second, you have wrote the word "security". So you really think that OBDC
>linked tables are anything but unsecure? If someone were to store something
>confidential like your credit card numbers, you would put your faith on an
>ODBC linked table?
>
>Question from the client: - We have a safe but we have some concerns about
>the safekeeping of the key because we are keeping under the rug.
>
>Solution from MS: no problem, we will remove it from under the mat and put
>it in plain sight on a table nearby. This way, not only you're sure that
>anyone around will see it but you're also sure that a thief won't hurt his
>back by bending down to take it.
>
>Client: - Great! But what happens if they are two or more thieves?
>
>MS: - Maybe we could put a machine for duplicating keys nearby?
>
>Client: - OK, but make sure that the user's manual is clear and easy to
>follow and don't forget the blanks!
>
>
>Finally, you have made a mention about the difficulty of managing
>server-side objects. Great, the next time that a secretary will call me for
>a request for a new set of data, I tell her that she'll have to look herself
>at the database's schema and make her own set of queries. This is for
>reading. Now, for writing, I wonder how many hours it will take before the
>database become corrupted when the users will start making their very own
>updating statements.
>
>Your notions of security and centralized management of database objects
>could be applied to a list of kitchen's recipes but I don't see how anyone
>would use those for an enterprise level database or any other serious
>business model.
>
>You're totally right when you said that ADPs have their share of problems.
>However, I'm afraid that the ADP's set of problem is only a very small
>subset of the whole collection held by JET's ODBC linked tables and
>passthrough queries. It's also true that MS is actually pushing people out
>of ADP but what they are pushed toward is - how could I say that politely -
>"questionable".
|
|
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl:
[Quoted Text] > It's hard to believe that MS itself is taking Access seriously
> when there is not even any certification for it.
I think your point of view is belied by the actions of the Access
development team in the recent time frame. Access has a new life
both as end-user tool and as developer platform, precisely because
of the decisions made in preparation for Access 2007.
Seems to me that MS has almost returned to the point of view about
Access that it had c. Office 95/97, where they were pushing Office
as a development platform for small and medium-sized businesses. MS
went way, way off track with Office 2000 and Access 2000, in my
opinion, and it's taken them this long to get back to the right
path.
In my opinion, ADPs were a bad idea based on stupid prejudices
rather than technical merit/need, and not really a
properly-implemented development platform. The development of ADPs
sapped resources that should have gone into the core Access
application. The fact that ADPs really are dead now (thankfully)
just points out the waste of resources. How much better Access could
have been for all users if they'd not been led down the garden path
by the crazy Enterprise development ideas that mostly came from
irrational fear of Jet.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98...
[Quoted Text] > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
> please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl:
>
>> It's hard to believe that MS itself is taking Access seriously
>> when there is not even any certification for it.
>
> I think your point of view is belied by the actions of the Access
> development team in the recent time frame. Access has a new life
> both as end-user tool and as developer platform, precisely because
> of the decisions made in preparation for Access 2007.
>
> Seems to me that MS has almost returned to the point of view about
> Access that it had c. Office 95/97, where they were pushing Office
> as a development platform for small and medium-sized businesses. MS
> went way, way off track with Office 2000 and Access 2000, in my
> opinion, and it's taken them this long to get back to the right
> path.
>
> In my opinion, ADPs were a bad idea based on stupid prejudices
> rather than technical merit/need, and not really a
> properly-implemented development platform. The development of ADPs
> sapped resources that should have gone into the core Access
> application. The fact that ADPs really are dead now (thankfully)
> just points out the waste of resources. How much better Access could
> have been for all users if they'd not been led down the garden path
> by the crazy Enterprise development ideas that mostly came from
> irrational fear of Jet.
Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, VB6,
etc., are all technologies based on COM/DCOM and MS is in the process of
killing all technologies based on these because you cannot make real object
oriented programming with COM/DCOM; only some sort of simulation; unlike
..NET which has been designed as an object oriented programming platform from
the ground up.
First, they have killed DNA (Distributed Network Architecture) before it got
even the chance of getting out of the laboratoray; then their next target
has been VB6 as well as a lot of smaller associated technologies like ADO,
VBScript, ASP Classic; etc. Did you really think that after having killed
these very big pieces of development platforms that were VB6, ASP Classic
and VBScript, that MS would be giving some serious toughts about keeeping
VBA and DAO in the long term?
I don't really understand how you can say that Access 2007 has got a new
life as a development platform when practically all the technological
development that have been made these last years are based on .NET and the
only thing that Access got was these small bones about Sharepoint; which, by
the way, are totally useless for anyone using SQL-Server as the backend.
They don't give a s**t about the technical merit/need of ADO vs DAO; all
they want is to get rid of COM/DCOM in the fatest way; so they are killing
these littles bunnies one after the other and it shouldn't take to long
before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally
absurd for anyone entering the field to learn VBA and DAO (as well as ADO);
so it doesn't take a big brain to see that there is absolutely no future
there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the
only difference if that some peoples using these don't know it yet.
The problem is not to know if there is a future or not for DAO and ADO
(there's none for both of them); the problem is to know what's the best
thing to do in the meantime before we can get our hands on a version of
Access with and integrated version to .NET.
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
|
|
David W. Fenton wrote:
[Quoted Text]
Yeah, seen that...their section on Access 2007 and SQL Server has been
copied without substantial change since the very first betas of Access 2007.
I just *love* the parts where they say it's "easier" (not necessarily
better) to optimize MDB/ACCDB solutions and then go on to admit that "there
are some scenarios where a report might be generated significantly faster in
an ADP file. [...] have the file load reports from a references ADP file."
Ummm...okay, so I'm jumping through the hoops of linking my perfectly viable
ADP solution into an MDB *why* again?
> Basically, it seems to me that MS realized that the effort to avoid
> using Jet was cutting off their nose to spite their face, in that
> whatever slowdowns Jet introduces (all of which can be worked
> around) it is incredibly flexible in terms of working with multiple
> data sources in different formats. The effort to eliminate the Jet
> layer resulted in the creation of another layer, and the end result
> is that they were back where the started from in terms of
> performance while also having sacrificed the amazing features of Jet
> that had been developed over the last 15 years.
And I'll agree, there are some advantages there, but honestly, I don't think
I've ever been called on to do things like joins from heterogeneous
sources...nor would I want to, generally, for the obvious performance
issues. If I *did* need to, I'd either go with a central-import solution or
do the reverse of the ADP linkage that MS suggests and link an MDB into an
ADP if I absolutely had to.
> MS's current policy is that MDB->ODBC->SQL Server is preferable to
> the ADP. That's the official statement (though you'll find lots of
> older MS documentation that still trumpets the ADP as the next best
> thing until the Second Coming).
That's funny because I still think it is! Yeah, there are bugs, but the
fact that you don't need to worry about linking in new and existing objects
is probably the biggest thing in ADP's favour in my books, not to mention
the fact that you KNOW all the processing will be done server-side instead
of the possibility that it'll try to download a whole lot of data over
potentially very narrow bandwidth to try to process it client-side.
To this day, I don't get why you'd ever want to use MDBs in a strictly
Access to SQL Server environment. Granted, local caching is easier in an
MDB, but it's not entirely un-doable in an ADP...you just have to use some
form of storage other than the ADP itself.
I just don't get why MS thinks that because THEY think MDBs are back to
being the preferred format that everybody else will naturally agree...and I
know I've seen other developers who have similar opinions about ADPs (not
counting Aaron Kempf, who will rabidly promote ADPs/SQL Server for
everything from a single-table local database to the entire international
banking system <grin>).
But hey, to each his or her own.
Rob
|
|
Sylvain, David et al,
You all raise very valid points. I encourage you to go register on
http://connect.microsoft.com/SQLServer and file Feedback bugs. Then
enlist your friends/colleagues to vote on them. If enough customers
want/require some specific piece of functionality, then it will get
more consideration from the product team. This isn't going to apply to
Access-specific features, but it does apply to all data access
technologies, not just SQL Server. This includes ODBC, OLEDB (classic
ADO), ADO.NET, LINQ to SQL and the Entity Framework. Having been on
the outside and now on the inside, my own personal agenda in all this
is to try to make things easier for developers seeking to
migrate/develop SQL Server apps regardless of the front-end tools they
use, and Connect seems to be the best way to make your voices heard.
That being said, there are often reasons for certain decisions that
are not made public, such as potential security vulnerabilities or
lack of internal resources. For example, updating ADPs to work with
later versions of SQL Server with the same range of functionality that
ADPs originally had would have been prohibitively expensive given the
relatively small number of Access-SQL developers compared to the
number of Access developers overall (somewhere in the neighborhood of
50 million). They would have had to cut features in the core product
that would have benefitted many to cater to the few. So it isn't about
Microsoft arbitrarily deciding to kill off various technologies --
these are business decisions, and sometimes Microsoft gets it wrong.
If you think they got it wrong for Access-SQL developers, go file a
Connect bug (or two).
--Mary
On Fri, 21 Nov 2008 00:03:54 -0500, "Sylvain Lafontaine" <sylvain aei
ca (fill the blanks, no spam please)> wrote:
[Quoted Text] >"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message >news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98... >> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam >> please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: >> >>> It's hard to believe that MS itself is taking Access seriously >>> when there is not even any certification for it. >> >> I think your point of view is belied by the actions of the Access >> development team in the recent time frame. Access has a new life >> both as end-user tool and as developer platform, precisely because >> of the decisions made in preparation for Access 2007. >> >> Seems to me that MS has almost returned to the point of view about >> Access that it had c. Office 95/97, where they were pushing Office >> as a development platform for small and medium-sized businesses. MS >> went way, way off track with Office 2000 and Access 2000, in my >> opinion, and it's taken them this long to get back to the right >> path. >> >> In my opinion, ADPs were a bad idea based on stupid prejudices >> rather than technical merit/need, and not really a >> properly-implemented development platform. The development of ADPs >> sapped resources that should have gone into the core Access >> application. The fact that ADPs really are dead now (thankfully) >> just points out the waste of resources. How much better Access could >> have been for all users if they'd not been led down the garden path >> by the crazy Enterprise development ideas that mostly came from >> irrational fear of Jet. > >Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, VB6, >etc., are all technologies based on COM/DCOM and MS is in the process of >killing all technologies based on these because you cannot make real object >oriented programming with COM/DCOM; only some sort of simulation; unlike >.NET which has been designed as an object oriented programming platform from >the ground up. > >First, they have killed DNA (Distributed Network Architecture) before it got >even the chance of getting out of the laboratoray; then their next target >has been VB6 as well as a lot of smaller associated technologies like ADO, >VBScript, ASP Classic; etc. Did you really think that after having killed >these very big pieces of development platforms that were VB6, ASP Classic >and VBScript, that MS would be giving some serious toughts about keeeping >VBA and DAO in the long term? > >I don't really understand how you can say that Access 2007 has got a new >life as a development platform when practically all the technological >development that have been made these last years are based on .NET and the >only thing that Access got was these small bones about Sharepoint; which, by >the way, are totally useless for anyone using SQL-Server as the backend. > >They don't give a s**t about the technical merit/need of ADO vs DAO; all >they want is to get rid of COM/DCOM in the fatest way; so they are killing >these littles bunnies one after the other and it shouldn't take to long >before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally >absurd for anyone entering the field to learn VBA and DAO (as well as ADO); >so it doesn't take a big brain to see that there is absolutely no future >there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the >only difference if that some peoples using these don't know it yet. > >The problem is not to know if there is a future or not for DAO and ADO >(there's none for both of them); the problem is to know what's the best >thing to do in the meantime before we can get our hands on a version of >Access with and integrated version to .NET. > >> -- >> David W. Fenton http://www.dfenton.com/>> usenet at dfenton dot com http://www.dfenton.com/DFA/ |
|
Oh, first thing, I would say that I'm totally in accord with the decision of
replacing VB6, VBScript and other things like ADO with .NET and that the
sooner the same will be done with VBA and DAO in Access, the better it will
be.
The problem that I have is with the message that MS is sending in the
meantime. When you read some of the posts from MS these last years, my
clients have the impression that keeping running with ADP is a dead-end
(right) but that going with VBA and DAO will be an investment in the future
(wrong).
Some years ago, any computer library would have been full of books on VB6,
VBSCript, ASP Classic and ADO; now, all these books are gone. However, when
you read some posts from MS, my clients got the impression that these books
have been replaced with books on DAO and VBA; clearly not the case when you
take a look by yourself but this is not something that my clients will do;
otherwise, they wouldn't pay me if they were capable of doing my job
themselves.
Furthermore, when you take a look at some posts like the following one from
Clint Covington about Macro coding under A2007:
http://blogs.msdn.com/clintcovington/archive/2007/03/29/millions-of-access-template-downloads-5-new-free-database.aspx ;
I'm not even sure if any scripting capabilities other than macros is in the
future of Access or if the decision has not already be made to transform
Access into some kind of point&click only interface. I can tell you that I
won't be surprised at all if the next version has some new features that can
be accessed only through macros, not VBA.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Mary Chipman [MSFT]" <mchip[ at ]online.microsoft.com> wrote in message
news:g1pdi4poi1j6c2tc19q8qf4mk2rinm9h4l[ at ]4ax.com...
[Quoted Text] > Sylvain, David et al, > > You all raise very valid points. I encourage you to go register on > http://connect.microsoft.com/SQLServer and file Feedback bugs. Then > enlist your friends/colleagues to vote on them. If enough customers > want/require some specific piece of functionality, then it will get > more consideration from the product team. This isn't going to apply to > Access-specific features, but it does apply to all data access > technologies, not just SQL Server. This includes ODBC, OLEDB (classic > ADO), ADO.NET, LINQ to SQL and the Entity Framework. Having been on > the outside and now on the inside, my own personal agenda in all this > is to try to make things easier for developers seeking to > migrate/develop SQL Server apps regardless of the front-end tools they > use, and Connect seems to be the best way to make your voices heard. > > That being said, there are often reasons for certain decisions that > are not made public, such as potential security vulnerabilities or > lack of internal resources. For example, updating ADPs to work with > later versions of SQL Server with the same range of functionality that > ADPs originally had would have been prohibitively expensive given the > relatively small number of Access-SQL developers compared to the > number of Access developers overall (somewhere in the neighborhood of > 50 million). They would have had to cut features in the core product > that would have benefitted many to cater to the few. So it isn't about > Microsoft arbitrarily deciding to kill off various technologies -- > these are business decisions, and sometimes Microsoft gets it wrong. > If you think they got it wrong for Access-SQL developers, go file a > Connect bug (or two). > > --Mary > > On Fri, 21 Nov 2008 00:03:54 -0500, "Sylvain Lafontaine" <sylvain aei > ca (fill the blanks, no spam please)> wrote: > >>"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message >>news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98... >>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam >>> please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: >>> >>>> It's hard to believe that MS itself is taking Access seriously >>>> when there is not even any certification for it. >>> >>> I think your point of view is belied by the actions of the Access >>> development team in the recent time frame. Access has a new life >>> both as end-user tool and as developer platform, precisely because >>> of the decisions made in preparation for Access 2007. >>> >>> Seems to me that MS has almost returned to the point of view about >>> Access that it had c. Office 95/97, where they were pushing Office >>> as a development platform for small and medium-sized businesses. MS >>> went way, way off track with Office 2000 and Access 2000, in my >>> opinion, and it's taken them this long to get back to the right >>> path. >>> >>> In my opinion, ADPs were a bad idea based on stupid prejudices >>> rather than technical merit/need, and not really a >>> properly-implemented development platform. The development of ADPs >>> sapped resources that should have gone into the core Access >>> application. The fact that ADPs really are dead now (thankfully) >>> just points out the waste of resources. How much better Access could >>> have been for all users if they'd not been led down the garden path >>> by the crazy Enterprise development ideas that mostly came from >>> irrational fear of Jet. >> >>Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, >>VB6, >>etc., are all technologies based on COM/DCOM and MS is in the process of >>killing all technologies based on these because you cannot make real >>object >>oriented programming with COM/DCOM; only some sort of simulation; unlike >>.NET which has been designed as an object oriented programming platform >>from >>the ground up. >> >>First, they have killed DNA (Distributed Network Architecture) before it >>got >>even the chance of getting out of the laboratoray; then their next target >>has been VB6 as well as a lot of smaller associated technologies like ADO, >>VBScript, ASP Classic; etc. Did you really think that after having killed >>these very big pieces of development platforms that were VB6, ASP Classic >>and VBScript, that MS would be giving some serious toughts about keeeping >>VBA and DAO in the long term? >> >>I don't really understand how you can say that Access 2007 has got a new >>life as a development platform when practically all the technological >>development that have been made these last years are based on .NET and the >>only thing that Access got was these small bones about Sharepoint; which, >>by >>the way, are totally useless for anyone using SQL-Server as the backend. >> >>They don't give a s**t about the technical merit/need of ADO vs DAO; all >>they want is to get rid of COM/DCOM in the fatest way; so they are killing >>these littles bunnies one after the other and it shouldn't take to long >>before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally >>absurd for anyone entering the field to learn VBA and DAO (as well as >>ADO); >>so it doesn't take a big brain to see that there is absolutely no future >>there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the >>only difference if that some peoples using these don't know it yet. >> >>The problem is not to know if there is a future or not for DAO and ADO >>(there's none for both of them); the problem is to know what's the best >>thing to do in the meantime before we can get our hands on a version of >>Access with and integrated version to .NET. >> >>> -- >>> David W. Fenton http://www.dfenton.com/>>> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Sorry, wrong reference:
http://blogs.msdn.com/clintcovington/archive/2007/02/15/macros-in-access-2007.aspx .
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:Oc2IDTATJHA.1484[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] > Oh, first thing, I would say that I'm totally in accord with the decision > of replacing VB6, VBScript and other things like ADO with .NET and that > the sooner the same will be done with VBA and DAO in Access, the better it > will be. > > The problem that I have is with the message that MS is sending in the > meantime. When you read some of the posts from MS these last years, my > clients have the impression that keeping running with ADP is a dead-end > (right) but that going with VBA and DAO will be an investment in the > future (wrong). > > Some years ago, any computer library would have been full of books on VB6, > VBSCript, ASP Classic and ADO; now, all these books are gone. However, > when you read some posts from MS, my clients got the impression that these > books have been replaced with books on DAO and VBA; clearly not the case > when you take a look by yourself but this is not something that my clients > will do; otherwise, they wouldn't pay me if they were capable of doing my > job themselves. > > Furthermore, when you take a look at some posts like the following one > from Clint Covington about Macro coding under A2007: > http://blogs.msdn.com/clintcovington/archive/2007/03/29/millions-of-access-template-downloads-5-new-free-database.aspx ; > I'm not even sure if any scripting capabilities other than macros is in > the future of Access or if the decision has not already be made to > transform Access into some kind of point&click only interface. I can tell > you that I won't be surprised at all if the next version has some new > features that can be accessed only through macros, not VBA. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > > "Mary Chipman [MSFT]" <mchip[ at ]online.microsoft.com> wrote in message > news:g1pdi4poi1j6c2tc19q8qf4mk2rinm9h4l[ at ]4ax.com... >> Sylvain, David et al, >> >> You all raise very valid points. I encourage you to go register on >> http://connect.microsoft.com/SQLServer and file Feedback bugs. Then >> enlist your friends/colleagues to vote on them. If enough customers >> want/require some specific piece of functionality, then it will get >> more consideration from the product team. This isn't going to apply to >> Access-specific features, but it does apply to all data access >> technologies, not just SQL Server. This includes ODBC, OLEDB (classic >> ADO), ADO.NET, LINQ to SQL and the Entity Framework. Having been on >> the outside and now on the inside, my own personal agenda in all this >> is to try to make things easier for developers seeking to >> migrate/develop SQL Server apps regardless of the front-end tools they >> use, and Connect seems to be the best way to make your voices heard. >> >> That being said, there are often reasons for certain decisions that >> are not made public, such as potential security vulnerabilities or >> lack of internal resources. For example, updating ADPs to work with >> later versions of SQL Server with the same range of functionality that >> ADPs originally had would have been prohibitively expensive given the >> relatively small number of Access-SQL developers compared to the >> number of Access developers overall (somewhere in the neighborhood of >> 50 million). They would have had to cut features in the core product >> that would have benefitted many to cater to the few. So it isn't about >> Microsoft arbitrarily deciding to kill off various technologies -- >> these are business decisions, and sometimes Microsoft gets it wrong. >> If you think they got it wrong for Access-SQL developers, go file a >> Connect bug (or two). >> >> --Mary >> >> On Fri, 21 Nov 2008 00:03:54 -0500, "Sylvain Lafontaine" <sylvain aei >> ca (fill the blanks, no spam please)> wrote: >> >>>"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message >>>news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98... >>>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam >>>> please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: >>>> >>>>> It's hard to believe that MS itself is taking Access seriously >>>>> when there is not even any certification for it. >>>> >>>> I think your point of view is belied by the actions of the Access >>>> development team in the recent time frame. Access has a new life >>>> both as end-user tool and as developer platform, precisely because >>>> of the decisions made in preparation for Access 2007. >>>> >>>> Seems to me that MS has almost returned to the point of view about >>>> Access that it had c. Office 95/97, where they were pushing Office >>>> as a development platform for small and medium-sized businesses. MS >>>> went way, way off track with Office 2000 and Access 2000, in my >>>> opinion, and it's taken them this long to get back to the right >>>> path. >>>> >>>> In my opinion, ADPs were a bad idea based on stupid prejudices >>>> rather than technical merit/need, and not really a >>>> properly-implemented development platform. The development of ADPs >>>> sapped resources that should have gone into the core Access >>>> application. The fact that ADPs really are dead now (thankfully) >>>> just points out the waste of resources. How much better Access could >>>> have been for all users if they'd not been led down the garden path >>>> by the crazy Enterprise development ideas that mostly came from >>>> irrational fear of Jet. >>> >>>Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, >>>VB6, >>>etc., are all technologies based on COM/DCOM and MS is in the process of >>>killing all technologies based on these because you cannot make real >>>object >>>oriented programming with COM/DCOM; only some sort of simulation; unlike >>>.NET which has been designed as an object oriented programming platform >>>from >>>the ground up. >>> >>>First, they have killed DNA (Distributed Network Architecture) before it >>>got >>>even the chance of getting out of the laboratoray; then their next target >>>has been VB6 as well as a lot of smaller associated technologies like >>>ADO, >>>VBScript, ASP Classic; etc. Did you really think that after having >>>killed >>>these very big pieces of development platforms that were VB6, ASP Classic >>>and VBScript, that MS would be giving some serious toughts about keeeping >>>VBA and DAO in the long term? >>> >>>I don't really understand how you can say that Access 2007 has got a new >>>life as a development platform when practically all the technological >>>development that have been made these last years are based on .NET and >>>the >>>only thing that Access got was these small bones about Sharepoint; which, >>>by >>>the way, are totally useless for anyone using SQL-Server as the backend. >>> >>>They don't give a s**t about the technical merit/need of ADO vs DAO; all >>>they want is to get rid of COM/DCOM in the fatest way; so they are >>>killing >>>these littles bunnies one after the other and it shouldn't take to long >>>before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally >>>absurd for anyone entering the field to learn VBA and DAO (as well as >>>ADO); >>>so it doesn't take a big brain to see that there is absolutely no future >>>there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the >>>only difference if that some peoples using these don't know it yet. >>> >>>The problem is not to know if there is a future or not for DAO and ADO >>>(there's none for both of them); the problem is to know what's the best >>>thing to do in the meantime before we can get our hands on a version of >>>Access with and integrated version to .NET. >>> >>>> -- >>>> David W. Fenton http://www.dfenton.com/>>>> usenet at dfenton dot com http://www.dfenton.com/DFA/> >
|
|
ADP were never a stupid idea, and they were never harder to use AT
ALL.
The development for queries - sprocs / views - is 100 times more
powerful than anything available in Jet.
Simple binding of a form to a sproc in Jet takes about 10 steps,
coding, and single-user access to the frontend.
None of those are necessary with GODS PLATFORM-- ADP.
On Nov 20, 7:15 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > please)> wrote innews:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: > > > It's hard to believe that MS itself is taking Access seriously > > when there is not even any certification for it. > > I think your point of view is belied by the actions of the Access > development team in the recent time frame. Access has a new life > both as end-user tool and as developer platform, precisely because > of the decisions made in preparation for Access 2007. > > Seems to me that MS has almost returned to the point of view about > Access that it had c. Office 95/97, where they were pushing Office > as a development platform for small and medium-sized businesses. MS > went way, way off track with Office 2000 and Access 2000, in my > opinion, and it's taken them this long to get back to the right > path. > > In my opinion, ADPs were a bad idea based on stupid prejudices > rather than technical merit/need, and not really a > properly-implemented development platform. The development of ADPs > sapped resources that should have gone into the core Access > application. The fact that ADPs really are dead now (thankfully) > just points out the waste of resources. How much better Access could > have been for all users if they'd not been led down the garden path > by the crazy Enterprise development ideas that mostly came from > irrational fear of Jet. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Irrational fear of jet?
The P.O.C. database crashes and runs slow with ~~25 mb of data!!!!
On Nov 20, 7:15 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > please)> wrote innews:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: > > > It's hard to believe that MS itself is taking Access seriously > > when there is not even any certification for it. > > I think your point of view is belied by the actions of the Access > development team in the recent time frame. Access has a new life > both as end-user tool and as developer platform, precisely because > of the decisions made in preparation for Access 2007. > > Seems to me that MS has almost returned to the point of view about > Access that it had c. Office 95/97, where they were pushing Office > as a development platform for small and medium-sized businesses. MS > went way, way off track with Office 2000 and Access 2000, in my > opinion, and it's taken them this long to get back to the right > path. > > In my opinion, ADPs were a bad idea based on stupid prejudices > rather than technical merit/need, and not really a > properly-implemented development platform. The development of ADPs > sapped resources that should have gone into the core Access > application. The fact that ADPs really are dead now (thankfully) > just points out the waste of resources. How much better Access could > have been for all users if they'd not been led down the garden path > by the crazy Enterprise development ideas that mostly came from > irrational fear of Jet. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
I don't agree with that.
I talked to someone on the Access team about a year ago, and they told
me that it will be here in 10 years and in 20 years.
It will just be dotnetified.
On Nov 19, 9:35 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > Oh, everyone here agree that ADP is a dead technology; doesn't take a big
> brain to figure that but it's not because ADP is inferior to ODBC linked
> tables but simply because MS has took the decision to put practically all
> the money toward developping .NET technologies instead of Access. Unless
> you're developping a database for storing the kitchen's recipes of your
> great, great, grand-mother or the friday night's hockey pool of your local
> pub, the gentle push that you're talking about is not toward ODBC linked
> tables but toward .NET. In MS's opinion, Access is geared toward usage, not
> development. This is why there is no Access certification at the present
> time. It's hard to believe that MS itself is taking Access seriously when
> there is not even any certification for it.
>
> In your previous post, you have said the following statement: « Basically it
> boils down flexibility, security and managing server-side objects. ... ».
> Well, then, first, we'll take a look at the word "flexibility". If ODBC
> linked tables are so flexible, can you explain to me why it's impossible to
> make any little complex statements without having JET saying that the
> expression is too complexe, to heavy on ressources, crashing or - in the
> best case scenario - see the performance dropping faster than a rock in free
> fall? Why is it that in 2008, something as simple as the following
> statement:
>
> SELECT T1.*, T2.*
> FROM T1 LEFT JOIN T2 ON (T1.Id1 = T2.Id2 and T2.Id2 = 10)
>
> make Access 2003 (didn't took the time to check for other versions) crash if
> T1 and T2 are ODBC linked tables (and that it will also crash for a lot of
> other simple constructs involving outer joins, subqueries and union
> queries).
>
> Make Access capable of doing some little complexe statements against ODBC
> linked tables without crashing a regularly as crash test dummy and we could
> talk about the technical capabilities of JET's ODBC linked tables. Make the
> result of passthrough queries read/write instead of read only and also make
> them available as record source for subreports and subforms for continuous
> forms and maybe that some people dealing with real enterprise databases will
> start looking at this stuff as potentially useful.
>
> And while you're on it, take also the time of solving your case-sensitivity
> and collation problems. The fact that in 2008, JET's queries against ODBC
> linked tables are still not offering full support for Unicode is practically
> unbelievable.
>
> Second, you have wrote the word "security". So you really think that OBDC
> linked tables are anything but unsecure? If someone were to store something
> confidential like your credit card numbers, you would put your faith on an
> ODBC linked table?
>
> Question from the client: - We have a safe but we have some concerns about
> the safekeeping of the key because we are keeping under the rug.
>
> Solution from MS: no problem, we will remove it from under the mat and put
> it in plain sight on a table nearby. This way, not only you're sure that
> anyone around will see it but you're also sure that a thief won't hurt his
> back by bending down to take it.
>
> Client: - Great! But what happens if they are two or more thieves?
>
> MS: - Maybe we could put a machine for duplicating keys nearby?
>
> Client: - OK, but make sure that the user's manual is clear and easy to
> follow and don't forget the blanks!
>
> Finally, you have made a mention about the difficulty of managing
> server-side objects. Great, the next time that a secretary will call me for
> a request for a new set of data, I tell her that she'll have to look herself
> at the database's schema and make her own set of queries. This is for
> reading. Now, for writing, I wonder how many hours it will take before the
> database become corrupted when the users will start making their very own
> updating statements.
>
> Your notions of security and centralized management of database objects
> could be applied to a list of kitchen's recipes but I don't see how anyone
> would use those for an enterprise level database or any other serious
> business model.
>
> You're totally right when you said that ADPs have their share of problems..
> However, I'm afraid that the ADP's set of problem is only a very small
> subset of the whole collection held by JET's ODBC linked tables and
> passthrough queries. It's also true that MS is actually pushing people out
> of ADP but what they are pushed toward is - how could I say that politely -
> "questionable".
>
> --
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
> "Mary Chipman [MSFT]" <mc...[ at ]online.microsoft.com> wrote in messagenews:4fb8i45u0c19iqqq194ak23eqisvqjluoc[ at ]4ax.com...
>
>
>
> > I'm not sure what your remarks mean, exactly. I've *always* been a
> > proponent of creating solutions that meet business needs, not the
> > other way around. Although I have in the past made many remarks to the
> > effect that I thought ADPs are a dead-end technology, that is strictly
> > my personal opinion. Many people have invested time and money in ADP
> > solutions, and Microsoft is committed to continuing to support them
> > while gently nudging new developers in the ODBC-linked table direction
> > for new Access-SQL apps. Hopefully the links to the whitepapers that
> > thoroughly explain the alternatives will achieve greater immortality
> > on the internet than my ramblings :)
>
> > --Mary
>
> > On Tue, 18 Nov 2008 10:55:12 -0500, "Sylvain Lafontaine" <sylvain aei
> > ca (fill the blanks, no spam please)> wrote:
>
> >>It's hard to believe that it's you, Mary C., who have just wrote that.
> >>However, now that you have wrote it, it will remains on the Internet
> >>forever.- Hide quoted text -
>
> - Show quoted text -
|
|
I'm sorry; I don't understand
'caching server side objects with XML'-- I know what you're talking
about.. I just don't think that any of that junk is necessary.
If your server objects don't run fast enough; take a class on SQL
Server
On Nov 18, 5:15 am, "Mary Chipman [MSFT]" <mc...[ at ]online.microsoft.com>
wrote:
[Quoted Text] > Basically it boils down flexibility, security and managing server-side > objects. With a linked table app, users can create their own > queries/views and they are saved on the client. Allowing users to > create/save their own views and stored procedures can create > management problems with clutter, assigning permissions, etc. Although > you can work around not caching server-side objects in ADPs by using > XML (etc), it takes a lot more work. That being said, many people find > ADPs tremendously useful for certain scenarios. As with any database > application, there is no "one size fits all" and Microsoft certainly > does not discourage ADPs for those who have weighed the alternatives > and find that ADPs best suit a particular business need. > > --Mary > > On Sun, 16 Nov 2008 10:20:01 -0800, "Mary Chipman [MSFT]" > > > > <mc...[ at ]online.microsoft.com> wrote: > >Is there a particular reason that you feel you need to use ADP's > >instead of linked tables? For new projects using Access-to-SQL Server, > >Microsoft recommends using ODBC links, although of course ADP's are > >also supported. Here are some other resources to help you decide which > >approach best suits your business needs. > > >--Mary > > >TechEd Online Panel (video): > >Go to http://msdn.microsoft.com/en-us/events/teched/cc676818.aspxand> >search for: > >"Are we there yet? Successfully navigating the bumpy road from Access > >to SQL Server" > > >Microsoft Access or SQL Server 2005: What's Right in Your > >Organization? > > http://www.microsoft.com/sql/solutions/migration/access/sql-or-access...> > >Optimizing Microsoft Office Access Applications Linked to SQL Server > > http://msdn.microsoft.com/en-us/library/bb188204.aspx> > >What are the main differences between Access and SQL Server? > > http://sqlserver2000.databases.aspfaq.com/what-are-the-main-differenc...> > >"The Best of Both Worlds--Access MDBs and SQL Server" > > http://www.jstreettech.com/cartgenie/pg_developerDownloads.asp> > >SQL Server Migration Assistant for Access (SSMA for Access) > > http://www.microsoft.com/sql/solutions/migration/access/default.mspx> > >FMS Upsizing Center > > http://www.fmsinc.com/Consulting/sqlupsizedocs.aspx> > >Microsoft Access Developer's Guide to SQL Server > > http://www.amazon.com/dp/0672319446> > >On Fri, 14 Nov 2008 08:06:01 -0800, Dave > ><D...[ at ]discussions.microsoft.com> wrote: > > >>I have inherited an access database that was converted from 2000 to 2007. The > >>tables were then uploaded to SQL and linked. Can the .mdb file be converted > >>to an .adp?- Hide quoted text - > > - Show quoted text -
|
|
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:uosbQa5SJHA.5900[ at ]TK2MSFTNGP05.phx.gbl:
[Quoted Text] > ADO (and ADP), VBA, VBScript, VB6,
> etc., are all technologies based on COM/DCOM and MS is in the
> process of killing all technologies based on these
I don't believe this for a moment. What will replace the Office
programs and the Office automation that millions of MS's customers
depend on?
I've been hearing "VBA IS DEAD!!!" and ".NET will replace VBA in the
next version of Office" for about half a decade or more now, and
nobody at MS ever says that this is true at all.
The reason I believe it's not true is because it's way too much work
to kill all those technologies without rewriting the entire Office
suite from the ground up. You may not have followed the Office Mac
VBA fiasco, but what happened there was the MS killed VBA in Office
2008 because they couldn't make it work as a universal Mac binary.
After that release, for whatever reason, MS decided it was worth
making it work after all, and the next version of Office Mac will
have VBA back.
Completely rewriting a non-Windows version of Office to use VBA does
not look to me like an indication of the imminent abandonment of
VBA. And the existence of VBA implies all the rest.
MS may *wish* it could force its customer base to stop mucking
around in all those technologies that make its job hard (in part
because MS didn't do its job properly in designing them in the first
place, 15-20 years ago), but that isn't going to happen because MS
would then be driving away most of its customer base.
Vista has shown that MS can't thrust bad products down the throat of
its customers. They aren't going to run the risk again of losing
their customers just to do the right thing (which the low-level
redesign in Vista clearly was).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:Oc2IDTATJHA.1484[ at ]TK2MSFTNGP03.phx.gbl:
[Quoted Text] > The problem that I have is with the message that MS is sending in
> the meantime. When you read some of the posts from MS these last
> years, my clients have the impression that keeping running with
> ADP is a dead-end (right) but that going with VBA and DAO will be
> an investment in the future (wrong).
Uh-huh. Access developers had this experience c. 1999, when MS told
them to switch to all the new technologies they introduced in Access
2000. Now, all those new technologies are completely dead, while all
the technologies that Access supported *before* that version are
still running strong and are in current development by the Access
team.
So, you might understand why, as an Access developer, I'm somewhat
skeptical of claims about new technologies from outside Access
replacing those that are so well-developed and widely supported
within Access itself.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
please)> wrote in news:Oc2IDTATJHA.1484[ at ]TK2MSFTNGP03.phx.gbl:
[Quoted Text] > I can tell you that I
> won't be surprised at all if the next version has some new
> features that can be accessed only through macros, not VBA.
If that's the case, it won't be Access any longer.
And, FWIW, I have not acquired Access 2007 and won't take any
development projects for it that are not done as MDBs. In other
words, no ribbon, no ACCDB. My clients don't need (and don't want)
these things, so I'm not about to invest any time in learning them.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
David W. Fenton wrote:
<snip>
[Quoted Text] > MS may *wish* it could force its customer base to stop mucking
> around in all those technologies that make its job hard (in part
> because MS didn't do its job properly in designing them in the first
> place, 15-20 years ago), but that isn't going to happen because MS
> would then be driving away most of its customer base.
>
> Vista has shown that MS can't thrust bad products down the throat of
> its customers. They aren't going to run the risk again of losing
> their customers just to do the right thing (which the low-level
> redesign in Vista clearly was).
Don't be so sure...they forced VB.NET onto VB6 developers with no recourse
but to adopt the new technology or switch to another platform altogether
(Delphi seems to be popular) if you wanted unmanaged code. Or stick with
the older VB, which many have, despite being...what?...10 years since the
last release?
Rob
|
|
Robert Morley <rmorley[ at ]N0.Freak1n.sparn.magma.ca> wrote in
news:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl:
[Quoted Text] > David W. Fenton wrote:
><snip>
>
>> MS may *wish* it could force its customer base to stop mucking
>> around in all those technologies that make its job hard (in part
>> because MS didn't do its job properly in designing them in the
>> first place, 15-20 years ago), but that isn't going to happen
>> because MS would then be driving away most of its customer base.
>>
>> Vista has shown that MS can't thrust bad products down the throat
>> of its customers. They aren't going to run the risk again of
>> losing their customers just to do the right thing (which the
>> low-level redesign in Vista clearly was).
>
> Don't be so sure...they forced VB.NET onto VB6 developers with no
> recourse but to adopt the new technology or switch to another
> platform altogether (Delphi seems to be popular) if you wanted
> unmanaged code. Or stick with the older VB, which many have,
> despite being...what?...10 years since the last release?
I have Access97 apps in production use at multiple clients. I don't
see a problem.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
« I have Access97 apps in production use at multiple clients. I don't see a
problem. »
Well, you have been able to describe the problem in a few words: since their
creation in 95, there have been practically no change in the way you can
access a SQL-Server from a MDB database file beside the use of ODBC linked
tables and passthrough queries. For all these years; the same complaints
have been made again and again ad viternam:
- When passthrough queries will become read/write instead of read-only?
- When will we be able to use passthrough queries for subreports and
subforms?
- When will we be able to use stored procedure for Insert/Update/Delete on
bound forms?
- When there will be support for application role?
- When will we get support for transactions on bound forms?
- When will we get something better than the current OLE Document Control
for storing and displaying images?
- When will full support for Unicode be implemented?
- Etc., etc., etc.
The only time that they have made something new was with adding the ADO
support and the ADP projects for working with SQL-Server. However, while OK
on many points and an amelioration in comparaison to ODBC linked tables and
passthrough queries; the ADPs have always remained an half baked product
with a lot of missing features and now, as they are going back in the past
by ceasing support for them and hinting that they will be removed in a
future version of Access, you call this an amelioration and a victory!?!?!
Since when doing nothing and resting at the same place over 13 years is an
amelioration and a victory?!?!?
Heck, even the Report Builder available for free for SQL-Express 2008 is now
better and more advanced than the reports available with Access. The only
thing that we have got for reports with Access 2007 is that we have lost the
possibility of setting a specific printer for each report. I don't call
this an amelioration.
Other products like SQL-Server got tons of new features with each new
versions while in the meantime, JET has been left in the cold for all these
years; with practically zero complaints solved. We are in 2008 and it's
still impossible to make something as simple as adding a few comments inside
a querydef! I won't pass any comment on the absence of Full Outer Join or
of any new other structure, on the insane need of putting parenthesis around
everything when doing multiple joins, its partical support for Unicode, the
absence of any graphical tool to see how your queries are executed by JET
and with which indexes or simply the concupiscious way that JET have in
reformating the text of querydefs. I won't even speak about the possibility
of having some advanced coding capabilities in querydefs like you can do
with stored procedures on SQL-Server since around the same time as Access
95.
When was the last time that you have seen something new for the JET engine?
Excerpt for some cosmetical changes here and there; practically nothing new
has been brought to Access over the last 13 years; not only for those
working with SQL-Server as the backend but also for all the other peoples
who use JET exclusively. The only thing that appears to happen is the
removal of features: they have removed its security model (it was weak but
at least, it was there) and its replication feature for the new ACCDB file
format, they are in the process of removing ADP, they have removed DAP
(instead of correcting its many bugs/flaws) and now, they want you to go
back to the use Macros instead of VBA code (or of any another advanced
scripting language).
You have said in a previous post: « - I think your point of view is belied
by the actions of the Access development team in the recent time frame.
Access has a new life both as end-user tool and as developer platform,
precisely because of the decisions made in preparation for Access 2007. ».
I don't know from where you are taking this perception about Access 2007 but
it must be from some parallel universe; where the laws of physic are
different.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns9B5EC3C9F96B6f99a49ed1d0c49c5bbb2[ at ]74.209.136.81...
[Quoted Text] > Robert Morley <rmorley[ at ]N0.Freak1n.sparn.magma.ca> wrote in > news:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl: > >> David W. Fenton wrote: >><snip> >> >>> MS may *wish* it could force its customer base to stop mucking >>> around in all those technologies that make its job hard (in part >>> because MS didn't do its job properly in designing them in the >>> first place, 15-20 years ago), but that isn't going to happen >>> because MS would then be driving away most of its customer base. >>> >>> Vista has shown that MS can't thrust bad products down the throat >>> of its customers. They aren't going to run the risk again of >>> losing their customers just to do the right thing (which the >>> low-level redesign in Vista clearly was). >> >> Don't be so sure...they forced VB.NET onto VB6 developers with no >> recourse but to adopt the new technology or switch to another >> platform altogether (Delphi seems to be popular) if you wanted >> unmanaged code. Or stick with the older VB, which many have, >> despite being...what?...10 years since the last release? > > I have Access97 apps in production use at multiple clients. I don't > see a problem. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
wow dude so you're still stuck using Access 97?
get with the times!!! RichText rocks!
On Nov 21, 7:53 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > please)> wrote innews:Oc2IDTATJHA.1484[ at ]TK2MSFTNGP03.phx.gbl: > > > I can tell you that I > > won't be surprised at all if the next version has some new > > features that can be accessed only through macros, not VBA. > > If that's the case, it won't be Access any longer. > > And, FWIW, I have not acquired Access 2007 and won't take any > development projects for it that are not done as MDBs. In other > words, no ribbon, no ACCDB. My clients don't need (and don't want) > these things, so I'm not about to invest any time in learning them. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
stability, performance, limited database size, bloat
you don't see a problem?
or you spend all your time writing workarounds?
On Nov 22, 4:14 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > Robert Morley <rmor...[ at ]N0.Freak1n.sparn.magma.ca> wrote innews:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl: > > > > > > > David W. Fenton wrote: > ><snip> > > >> MS may *wish* it could force its customer base to stop mucking > >> around in all those technologies that make its job hard (in part > >> because MS didn't do its job properly in designing them in the > >> first place, 15-20 years ago), but that isn't going to happen > >> because MS would then be driving away most of its customer base. > > >> Vista has shown that MS can't thrust bad products down the throat > >> of its customers. They aren't going to run the risk again of > >> losing their customers just to do the right thing (which the > >> low-level redesign in Vista clearly was). > > > Don't be so sure...they forced VB.NET onto VB6 developers with no > > recourse but to adopt the new technology or switch to another > > platform altogether (Delphi seems to be popular) if you wanted > > unmanaged code. Or stick with the older VB, which many have, > > despite being...what?...10 years since the last release? > > I have Access97 apps in production use at multiple clients. I don't > see a problem. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/- Hide quoted text - > > - Show quoted text -
|
|
I don't think that ADP are a half-baked product. I think that they're
great!
I really don't think that I've hit a bug in ADP in the past 5-6 years,
honestly.
On Nov 22, 11:49 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > « I have Access97 apps in production use at multiple clients. I don't see a > problem. » > > Well, you have been able to describe the problem in a few words: since their > creation in 95, there have been practically no change in the way you can > access a SQL-Server from a MDB database file beside the use of ODBC linked > tables and passthrough queries. For all these years; the same complaints > have been made again and again ad viternam: > > - When passthrough queries will become read/write instead of read-only? > > - When will we be able to use passthrough queries for subreports and > subforms? > > - When will we be able to use stored procedure for Insert/Update/Delete on > bound forms? > > - When there will be support for application role? > > - When will we get support for transactions on bound forms? > > - When will we get something better than the current OLE Document Control > for storing and displaying images? > > - When will full support for Unicode be implemented? > > - Etc., etc., etc. > > The only time that they have made something new was with adding the ADO > support and the ADP projects for working with SQL-Server. However, while OK > on many points and an amelioration in comparaison to ODBC linked tables and > passthrough queries; the ADPs have always remained an half baked product > with a lot of missing features and now, as they are going back in the past > by ceasing support for them and hinting that they will be removed in a > future version of Access, you call this an amelioration and a victory!?!?! > > Since when doing nothing and resting at the same place over 13 years is an > amelioration and a victory?!?!? > > Heck, even the Report Builder available for free for SQL-Express 2008 is now > better and more advanced than the reports available with Access. The only > thing that we have got for reports with Access 2007 is that we have lost the > possibility of setting a specific printer for each report. I don't call > this an amelioration. > > Other products like SQL-Server got tons of new features with each new > versions while in the meantime, JET has been left in the cold for all these > years; with practically zero complaints solved. We are in 2008 and it's > still impossible to make something as simple as adding a few comments inside > a querydef! I won't pass any comment on the absence of Full Outer Join or > of any new other structure, on the insane need of putting parenthesis around > everything when doing multiple joins, its partical support for Unicode, the > absence of any graphical tool to see how your queries are executed by JET > and with which indexes or simply the concupiscious way that JET have in > reformating the text of querydefs. I won't even speak about the possibility > of having some advanced coding capabilities in querydefs like you can do > with stored procedures on SQL-Server since around the same time as Access > 95. > > When was the last time that you have seen something new for the JET engine? > > Excerpt for some cosmetical changes here and there; practically nothing new > has been brought to Access over the last 13 years; not only for those > working with SQL-Server as the backend but also for all the other peoples > who use JET exclusively. The only thing that appears to happen is the > removal of features: they have removed its security model (it was weak but > at least, it was there) and its replication feature for the new ACCDB file > format, they are in the process of removing ADP, they have removed DAP > (instead of correcting its many bugs/flaws) and now, they want you to go > back to the use Macros instead of VBA code (or of any another advanced > scripting language). > > You have said in a previous post: « - I think your point of view is belied > by the actions of the Access development team in the recent time frame. > Access has a new life both as end-user tool and as developer platform, > precisely because of the decisions made in preparation for Access 2007. ». > > I don't know from where you are taking this perception about Access 2007 but > it must be from some parallel universe; where the laws of physic are > different. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid> wrote in messagenews:Xns9B5EC3C9F96B6f99a49ed1d0c49c5bbb2[ at ]74.209.136.81... > > > > > Robert Morley <rmor...[ at ]N0.Freak1n.sparn.magma.ca> wrote in > >news:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl: > > >> David W. Fenton wrote: > >><snip> > > >>> MS may *wish* it could force its customer base to stop mucking > >>> around in all those technologies that make its job hard (in part > >>> because MS didn't do its job properly in designing them in the > >>> first place, 15-20 years ago), but that isn't going to happen > >>> because MS would then be driving away most of its customer base. > > >>> Vista has shown that MS can't thrust bad products down the throat > >>> of its customers. They aren't going to run the risk again of > >>> losing their customers just to do the right thing (which the > >>> low-level redesign in Vista clearly was). > > >> Don't be so sure...they forced VB.NET onto VB6 developers with no > >> recourse but to adopt the new technology or switch to another > >> platform altogether (Delphi seems to be popular) if you wanted > >> unmanaged code. Or stick with the older VB, which many have, > >> despite being...what?...10 years since the last release? > > > I have Access97 apps in production use at multiple clients. I don't > > see a problem. > > > -- > > David W. Fenton http://www.dfenton.com/> > usenet at dfenton dot com http://www.dfenton.com/DFA/- Hide quoted text - > > - Show quoted text -
|
|
David;
those new techs are not dead-- ADP is alive and well, and it will be
for a long time.
And really-- honestly-- Jet still corrupts, it still bloats, and it's
still too slow for enterprise use.
So if you've got a choice between 'good enough' and 'not good enough'
then ADP falls in the good enough category, where Jet hasn't been
reliable enough for me for a long long long time.
I've worked in a dozen environments where we have ~~1gb of data in
jet.
Every single time- moving to SQL Server (ADP) is a no-brainer.
Do you thnk that Starbucks uses Jet to manage their operations
centers? Their products? Their financials?
Do you thnk that Microsoft uses Jet to manage their product lineup? Do
you think that Jet is used for anything at Microsoft?
Do you thnk that Safeco uses Jet to manage their claims?
Do you think that Expedia uses Jet to manage their financial
applications?
On Nov 21, 7:52 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > please)> wrote innews:Oc2IDTATJHA.1484[ at ]TK2MSFTNGP03.phx.gbl: > > > The problem that I have is with the message that MS is sending in > > the meantime. When you read some of the posts from MS these last > > years, my clients have the impression that keeping running with > > ADP is a dead-end (right) but that going with VBA and DAO will be > > an investment in the future (wrong). > > Uh-huh. Access developers had this experience c. 1999, when MS told > them to switch to all the new technologies they introduced in Access > 2000. Now, all those new technologies are completely dead, while all > the technologies that Access supported *before* that version are > still running strong and are in current development by the Access > team. > > So, you might understand why, as an Access developer, I'm somewhat > skeptical of claims about new technologies from outside Access > replacing those that are so well-developed and widely supported > within Access itself. > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Vista was a success. MacFags don't change anything.
Re: 'MS didn't do its job properly in designing them in the first
place, 15-20 years ago'
THAT IS WHY THEY CAME OUT WITH A MULTIUSER VERSION OF MS ACCESS BACK
IN 2000. IT IS CALLED ADP, AND IT TRUMPS ANYTHING AVAILABLE IN JET!
On Nov 21, 7:47 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > please)> wrote innews:uosbQa5SJHA.5900[ at ]TK2MSFTNGP05.phx.gbl: > > > ADO (and ADP), VBA, VBScript, VB6, > > etc., are all technologies based on COM/DCOM and MS is in the > > process of killing all technologies based on these > > I don't believe this for a moment. What will replace the Office > programs and the Office automation that millions of MS's customers > depend on? > > I've been hearing "VBA IS DEAD!!!" and ".NET will replace VBA in the > next version of Office" for about half a decade or more now, and > nobody at MS ever says that this is true at all. > > The reason I believe it's not true is because it's way too much work > to kill all those technologies without rewriting the entire Office > suite from the ground up. You may not have followed the Office Mac > VBA fiasco, but what happened there was the MS killed VBA in Office > 2008 because they couldn't make it work as a universal Mac binary. > After that release, for whatever reason, MS decided it was worth > making it work after all, and the next version of Office Mac will > have VBA back. > > Completely rewriting a non-Windows version of Office to use VBA does > not look to me like an indication of the imminent abandonment of > VBA. And the existence of VBA implies all the rest. > > MS may *wish* it could force its customer base to stop mucking > around in all those technologies that make its job hard (in part > because MS didn't do its job properly in designing them in the first > place, 15-20 years ago), but that isn't going to happen because MS > would then be driving away most of its customer base. > > Vista has shown that MS can't thrust bad products down the throat of > its customers. They aren't going to run the risk again of losing > their customers just to do the right thing (which the low-level > redesign in Vista clearly was). > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
I've been in this newsgroup since 5-6 years and I've seen a collection of
them (bugs); including many of them who have been followed by hotfixes.
However, by half-baked, I'm not speaking about the bugs - every application
has them - I'm speaking about the missing features; some of them that have
been promised for so long that they have even been included in the official
documentation for some time (here, I'm talking about the control over
transactions for bound forms).
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:96a74a87-9c41-4c3f-b4f7-457d5578fb6b[ at ]a3g2000prm.googlegroups.com...
I don't think that ADP are a half-baked product. I think that they're
great!
I really don't think that I've hit a bug in ADP in the past 5-6 years,
honestly.
On Nov 22, 11:49 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > « I have Access97 apps in production use at multiple clients. I don't see > a > problem. » > > Well, you have been able to describe the problem in a few words: since > their > creation in 95, there have been practically no change in the way you can > access a SQL-Server from a MDB database file beside the use of ODBC linked > tables and passthrough queries. For all these years; the same complaints > have been made again and again ad viternam: > > - When passthrough queries will become read/write instead of read-only? > > - When will we be able to use passthrough queries for subreports and > subforms? > > - When will we be able to use stored procedure for Insert/Update/Delete on > bound forms? > > - When there will be support for application role? > > - When will we get support for transactions on bound forms? > > - When will we get something better than the current OLE Document Control > for storing and displaying images? > > - When will full support for Unicode be implemented? > > - Etc., etc., etc. > > The only time that they have made something new was with adding the ADO > support and the ADP projects for working with SQL-Server. However, while > OK > on many points and an amelioration in comparaison to ODBC linked tables > and > passthrough queries; the ADPs have always remained an half baked product > with a lot of missing features and now, as they are going back in the past > by ceasing support for them and hinting that they will be removed in a > future version of Access, you call this an amelioration and a victory!?!?! > > Since when doing nothing and resting at the same place over 13 years is an > amelioration and a victory?!?!? > > Heck, even the Report Builder available for free for SQL-Express 2008 is > now > better and more advanced than the reports available with Access. The only > thing that we have got for reports with Access 2007 is that we have lost > the > possibility of setting a specific printer for each report. I don't call > this an amelioration. > > Other products like SQL-Server got tons of new features with each new > versions while in the meantime, JET has been left in the cold for all > these > years; with practically zero complaints solved. We are in 2008 and it's > still impossible to make something as simple as adding a few comments > inside > a querydef! I won't pass any comment on the absence of Full Outer Join or > of any new other structure, on the insane need of putting parenthesis > around > everything when doing multiple joins, its partical support for Unicode, > the > absence of any graphical tool to see how your queries are executed by JET > and with which indexes or simply the concupiscious way that JET have in > reformating the text of querydefs. I won't even speak about the > possibility > of having some advanced coding capabilities in querydefs like you can do > with stored procedures on SQL-Server since around the same time as Access > 95. > > When was the last time that you have seen something new for the JET > engine? > > Excerpt for some cosmetical changes here and there; practically nothing > new > has been brought to Access over the last 13 years; not only for those > working with SQL-Server as the backend but also for all the other peoples > who use JET exclusively. The only thing that appears to happen is the > removal of features: they have removed its security model (it was weak but > at least, it was there) and its replication feature for the new ACCDB file > format, they are in the process of removing ADP, they have removed DAP > (instead of correcting its many bugs/flaws) and now, they want you to go > back to the use Macros instead of VBA code (or of any another advanced > scripting language). > > You have said in a previous post: « - I think your point of view is belied > by the actions of the Access development team in the recent time frame. > Access has a new life both as end-user tool and as developer platform, > precisely because of the decisions made in preparation for Access 2007. ». > > I don't know from where you are taking this perception about Access 2007 > but > it must be from some parallel universe; where the laws of physic are > different. > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid> wrote in > messagenews:Xns9B5EC3C9F96B6f99a49ed1d0c49c5bbb2[ at ]74.209.136.81... > > > > > Robert Morley <rmor...[ at ]N0.Freak1n.sparn.magma.ca> wrote in > >news:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl: > > >> David W. Fenton wrote: > >><snip> > > >>> MS may *wish* it could force its customer base to stop mucking > >>> around in all those technologies that make its job hard (in part > >>> because MS didn't do its job properly in designing them in the > >>> first place, 15-20 years ago), but that isn't going to happen > >>> because MS would then be driving away most of its customer base. > > >>> Vista has shown that MS can't thrust bad products down the throat > >>> of its customers. They aren't going to run the risk again of > >>> losing their customers just to do the right thing (which the > >>> low-level redesign in Vista clearly was). > > >> Don't be so sure...they forced VB.NET onto VB6 developers with no > >> recourse but to adopt the new technology or switch to another > >> platform altogether (Delphi seems to be popular) if you wanted > >> unmanaged code. Or stick with the older VB, which many have, > >> despite being...what?...10 years since the last release? > > > I have Access97 apps in production use at multiple clients. I don't > > see a problem. > > > -- > > David W. Fenton http://www.dfenton.com/> > usenet at dfenton dot com http://www.dfenton.com/DFA/- Hide quoted > > text - > > - Show quoted text -
|
|
well I've been using them since 99 (member of Office Premium Partner
program back then) and I haven't had any problems with them since
about 2002.
I just think that they're a wonderful platform. SQL Server-- even
with the other components is just an awesome platform.
Jet isn't usable for 25mb of data.
I've not had a problem in ADP in the past 5-6 years.
Meanwhile, Jet makes you write connection strings when you move
servers, etc.
In ADP, it's a single file,connection-- I just think that companies
should use ADP for everything.
And Jet isn't reliable enough for a simple library / tracking
database.
-Aaron
On Nov 23, 10:52 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > I've been in this newsgroup since 5-6 years and I've seen a collection of > them (bugs); including many of them who have been followed by hotfixes. > However, by half-baked, I'm not speaking about the bugs - every application > has them - I'm speaking about the missing features; some of them that have > been promised for so long that they have even been included in the official > documentation for some time (here, I'm talking about the control over > transactions for bound forms). > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > "a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.ke...[ at ]gmail.com> wrote in > messagenews:96a74a87-9c41-4c3f-b4f7-457d5578fb6b[ at ]a3g2000prm.googlegroups.com... > I don't think that ADP are a half-baked product. I think that they're > great! > I really don't think that I've hit a bug in ADP in the past 5-6 years, > honestly. > > On Nov 22, 11:49 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the > blanks, no spam please)> wrote: > > > > > « I have Access97 apps in production use at multiple clients. I don't see > > a > > problem. » > > > Well, you have been able to describe the problem in a few words: since > > their > > creation in 95, there have been practically no change in the way you can > > access a SQL-Server from a MDB database file beside the use of ODBC linked > > tables and passthrough queries. For all these years; the same complaints > > have been made again and again ad viternam: > > > - When passthrough queries will become read/write instead of read-only? > > > - When will we be able to use passthrough queries for subreports and > > subforms? > > > - When will we be able to use stored procedure for Insert/Update/Delete on > > bound forms? > > > - When there will be support for application role? > > > - When will we get support for transactions on bound forms? > > > - When will we get something better than the current OLE Document Control > > for storing and displaying images? > > > - When will full support for Unicode be implemented? > > > - Etc., etc., etc. > > > The only time that they have made something new was with adding the ADO > > support and the ADP projects for working with SQL-Server. However, while > > OK > > on many points and an amelioration in comparaison to ODBC linked tables > > and > > passthrough queries; the ADPs have always remained an half baked product > > with a lot of missing features and now, as they are going back in the past > > by ceasing support for them and hinting that they will be removed in a > > future version of Access, you call this an amelioration and a victory!?!?! > > > Since when doing nothing and resting at the same place over 13 years is an > > amelioration and a victory?!?!? > > > Heck, even the Report Builder available for free for SQL-Express 2008 is > > now > > better and more advanced than the reports available with Access. The only > > thing that we have got for reports with Access 2007 is that we have lost > > the > > possibility of setting a specific printer for each report. I don't call > > this an amelioration. > > > Other products like SQL-Server got tons of new features with each new > > versions while in the meantime, JET has been left in the cold for all > > these > > years; with practically zero complaints solved. We are in 2008 and it's > > still impossible to make something as simple as adding a few comments > > inside > > a querydef! I won't pass any comment on the absence of Full Outer Join or > > of any new other structure, on the insane need of putting parenthesis > > around > > everything when doing multiple joins, its partical support for Unicode, > > the > > absence of any graphical tool to see how your queries are executed by JET > > and with which indexes or simply the concupiscious way that JET have in > > reformating the text of querydefs. I won't even speak about the > > possibility > > of having some advanced coding capabilities in querydefs like you can do > > with stored procedures on SQL-Server since around the same time as Access > > 95. > > > When was the last time that you have seen something new for the JET > > engine? > > > Excerpt for some cosmetical changes here and there; practically nothing > > new > > has been brought to Access over the last 13 years; not only for those > > working with SQL-Server as the backend but also for all the other peoples > > who use JET exclusively. The only thing that appears to happen is the > > removal of features: they have removed its security model (it was weak but > > at least, it was there) and its replication feature for the new ACCDB file > > format, they are in the process of removing ADP, they have removed DAP > > (instead of correcting its many bugs/flaws) and now, they want you to go > > back to the use Macros instead of VBA code (or of any another advanced > > scripting language). > > > You have said in a previous post: « - I think your point of view is belied > > by the actions of the Access development team in the recent time frame. > > Access has a new life both as end-user tool and as developer platform, > > precisely because of the decisions made in preparation for Access 2007. ». > > > I don't know from where you are taking this perception about Access 2007 > > but > > it must be from some parallel universe; where the laws of physic are > > different. > > > -- > > Sylvain Lafontaine, ing. > > MVP - Technologies Virtual-PC > > E-mail: sylvain aei ca (fill the blanks, no spam please) > > > "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid> wrote in > > messagenews:Xns9B5EC3C9F96B6f99a49ed1d0c49c5bbb2[ at ]74.209.136.81... > > > > Robert Morley <rmor...[ at ]N0.Freak1n.sparn.magma.ca> wrote in > > >news:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl: > > > >> David W. Fenton wrote: > > >><snip> > > > >>> MS may *wish* it could force its customer base to stop mucking > > >>> around in all those technologies that make its job hard (in part > > >>> because MS didn't do its job properly in designing them in the > > >>> first place, 15-20 years ago), but that isn't going to happen > > >>> because MS would then be driving away most of its customer base. > > > >>> Vista has shown that MS can't thrust bad products down the throat > > >>> of its customers. They aren't going to run the risk again of > > >>> losing their customers just to do the right thing (which the > > >>> low-level redesign in Vista clearly was). > > > >> Don't be so sure...they forced VB.NET onto VB6 developers with no > > >> recourse but to adopt the new technology or switch to another > > >> platform altogether (Delphi seems to be popular) if you wanted > > >> unmanaged code. Or stick with the older VB, which many have, > > >> despite being...what?...10 years since the last release? > > > > I have Access97 apps in production use at multiple clients. I don't > > > see a problem. > > > > -- > > > David W. Fenton http://www.dfenton.com/> > > usenet at dfenton dot com http://www.dfenton.com/DFA/-Hide quoted > > > text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -
|
|
and I don't think that I have any problems with transactions and bound
forms.
I use bound forms for almost everything I do.
Sometimes, I have to write a line or two of VBA-- that's not the end
of the world.
And I might requery a form or two 10% more often than I absolutely
need to.
But the ability to _INDEX_ SQL Server means that it's possible, it's
easy-- to adequately index SQL Server.
the same thing in Jet takes hours and hours of manual tests.
A _LOT_ of the ADPs that I use.. and simply a development point for
writing procedural scripts that run in VBA, these are quite easy to
move to SQL Server Agent.
Scheduling code to run over time is priceless-- and I'll put that in
the category of 'Stuff that Jet Doesn't Have, and it never will'.
On Nov 23, 10:52 am, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > I've been in this newsgroup since 5-6 years and I've seen a collection of > them (bugs); including many of them who have been followed by hotfixes. > However, by half-baked, I'm not speaking about the bugs - every application > has them - I'm speaking about the missing features; some of them that have > been promised for so long that they have even been included in the official > documentation for some time (here, I'm talking about the control over > transactions for bound forms). > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > "a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.ke...[ at ]gmail.com> wrote in > messagenews:96a74a87-9c41-4c3f-b4f7-457d5578fb6b[ at ]a3g2000prm.googlegroups.com... > I don't think that ADP are a half-baked product. I think that they're > great! > I really don't think that I've hit a bug in ADP in the past 5-6 years, > honestly. > > On Nov 22, 11:49 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the > blanks, no spam please)> wrote: > > > > > « I have Access97 apps in production use at multiple clients. I don't see > > a > > problem. » > > > Well, you have been able to describe the problem in a few words: since > > their > > creation in 95, there have been practically no change in the way you can > > access a SQL-Server from a MDB database file beside the use of ODBC linked > > tables and passthrough queries. For all these years; the same complaints > > have been made again and again ad viternam: > > > - When passthrough queries will become read/write instead of read-only? > > > - When will we be able to use passthrough queries for subreports and > > subforms? > > > - When will we be able to use stored procedure for Insert/Update/Delete on > > bound forms? > > > - When there will be support for application role? > > > - When will we get support for transactions on bound forms? > > > - When will we get something better than the current OLE Document Control > > for storing and displaying images? > > > - When will full support for Unicode be implemented? > > > - Etc., etc., etc. > > > The only time that they have made something new was with adding the ADO > > support and the ADP projects for working with SQL-Server. However, while > > OK > > on many points and an amelioration in comparaison to ODBC linked tables > > and > > passthrough queries; the ADPs have always remained an half baked product > > with a lot of missing features and now, as they are going back in the past > > by ceasing support for them and hinting that they will be removed in a > > future version of Access, you call this an amelioration and a victory!?!?! > > > Since when doing nothing and resting at the same place over 13 years is an > > amelioration and a victory?!?!? > > > Heck, even the Report Builder available for free for SQL-Express 2008 is > > now > > better and more advanced than the reports available with Access. The only > > thing that we have got for reports with Access 2007 is that we have lost > > the > > possibility of setting a specific printer for each report. I don't call > > this an amelioration. > > > Other products like SQL-Server got tons of new features with each new > > versions while in the meantime, JET has been left in the cold for all > > these > > years; with practically zero complaints solved. We are in 2008 and it's > > still impossible to make something as simple as adding a few comments > > inside > > a querydef! I won't pass any comment on the absence of Full Outer Join or > > of any new other structure, on the insane need of putting parenthesis > > around > > everything when doing multiple joins, its partical support for Unicode, > > the > > absence of any graphical tool to see how your queries are executed by JET > > and with which indexes or simply the concupiscious way that JET have in > > reformating the text of querydefs. I won't even speak about the > > possibility > > of having some advanced coding capabilities in querydefs like you can do > > with stored procedures on SQL-Server since around the same time as Access > > 95. > > > When was the last time that you have seen something new for the JET > > engine? > > > Excerpt for some cosmetical changes here and there; practically nothing > > new > > has been brought to Access over the last 13 years; not only for those > > working with SQL-Server as the backend but also for all the other peoples > > who use JET exclusively. The only thing that appears to happen is the > > removal of features: they have removed its security model (it was weak but > > at least, it was there) and its replication feature for the new ACCDB file > > format, they are in the process of removing ADP, they have removed DAP > > (instead of correcting its many bugs/flaws) and now, they want you to go > > back to the use Macros instead of VBA code (or of any another advanced > > scripting language). > > > You have said in a previous post: « - I think your point of view is belied > > by the actions of the Access development team in the recent time frame. > > Access has a new life both as end-user tool and as developer platform, > > precisely because of the decisions made in preparation for Access 2007. ». > > > I don't know from where you are taking this perception about Access 2007 > > but > > it must be from some parallel universe; where the laws of physic are > > different. > > > -- > > Sylvain Lafontaine, ing. > > MVP - Technologies Virtual-PC > > E-mail: sylvain aei ca (fill the blanks, no spam please) > > > "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid> wrote in > > messagenews:Xns9B5EC3C9F96B6f99a49ed1d0c49c5bbb2[ at ]74.209.136.81... > > > > Robert Morley <rmor...[ at ]N0.Freak1n.sparn.magma.ca> wrote in > > >news:OZI#jdFTJHA.4372[ at ]TK2MSFTNGP04.phx.gbl: > > > >> David W. Fenton wrote: > > >><snip> > > > >>> MS may *wish* it could force its customer base to stop mucking > > >>> around in all those technologies that make its job hard (in part > > >>> because MS didn't do its job properly in designing them in the > > >>> first place, 15-20 years ago), but that isn't going to happen > > >>> because MS would then be driving away most of its customer base. > > > >>> Vista has shown that MS can't thrust bad products down the throat > > >>> of its customers. They aren't going to run the risk again of > > >>> losing their customers just to do the right thing (which the > > >>> low-level redesign in Vista clearly was). > > > >> Don't be so sure...they forced VB.NET onto VB6 developers with no > > >> recourse but to adopt the new technology or switch to another > > >> platform altogether (Delphi seems to be popular) if you wanted > > >> unmanaged code. Or stick with the older VB, which many have, > > >> despite being...what?...10 years since the last release? > > > > I have Access97 apps in production use at multiple clients. I don't > > > see a problem. > > > > -- > > > David W. Fenton http://www.dfenton.com/> > > usenet at dfenton dot com http://www.dfenton.com/DFA/-Hide quoted > > > text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text -
|
|
Dear Sylvain,
I seem to have come into the middle of a debate about ADP/Access/COM/DCOM
and I wish I could give a considered opinion however:-
I am a hard working database designer, working for myself and I sense my
livelihood is threatened. Would you be so kind as to answer the following Q's
1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP (Service
Pack?)
2 - Should I now convert to Access2007 if the answer to 1 is NO
3 - If clients want ADP's, as mine seem to do, for the low end database
applications should I be recommending that SQL 2000 is retained for such
applications
Thank you
--
Bob Snedden, MCT, MCSD.Net
"Sylvain Lafontaine" wrote:
[Quoted Text] > "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message > news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98... > > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > > please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: > > > >> It's hard to believe that MS itself is taking Access seriously > >> when there is not even any certification for it. > > > > I think your point of view is belied by the actions of the Access > > development team in the recent time frame. Access has a new life > > both as end-user tool and as developer platform, precisely because > > of the decisions made in preparation for Access 2007. > > > > Seems to me that MS has almost returned to the point of view about > > Access that it had c. Office 95/97, where they were pushing Office > > as a development platform for small and medium-sized businesses. MS > > went way, way off track with Office 2000 and Access 2000, in my > > opinion, and it's taken them this long to get back to the right > > path. > > > > In my opinion, ADPs were a bad idea based on stupid prejudices > > rather than technical merit/need, and not really a > > properly-implemented development platform. The development of ADPs > > sapped resources that should have gone into the core Access > > application. The fact that ADPs really are dead now (thankfully) > > just points out the waste of resources. How much better Access could > > have been for all users if they'd not been led down the garden path > > by the crazy Enterprise development ideas that mostly came from > > irrational fear of Jet. > > Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, VB6, > etc., are all technologies based on COM/DCOM and MS is in the process of > killing all technologies based on these because you cannot make real object > oriented programming with COM/DCOM; only some sort of simulation; unlike > ..NET which has been designed as an object oriented programming platform from > the ground up. > > First, they have killed DNA (Distributed Network Architecture) before it got > even the chance of getting out of the laboratoray; then their next target > has been VB6 as well as a lot of smaller associated technologies like ADO, > VBScript, ASP Classic; etc. Did you really think that after having killed > these very big pieces of development platforms that were VB6, ASP Classic > and VBScript, that MS would be giving some serious toughts about keeeping > VBA and DAO in the long term? > > I don't really understand how you can say that Access 2007 has got a new > life as a development platform when practically all the technological > development that have been made these last years are based on .NET and the > only thing that Access got was these small bones about Sharepoint; which, by > the way, are totally useless for anyone using SQL-Server as the backend. > > They don't give a s**t about the technical merit/need of ADO vs DAO; all > they want is to get rid of COM/DCOM in the fatest way; so they are killing > these littles bunnies one after the other and it shouldn't take to long > before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally > absurd for anyone entering the field to learn VBA and DAO (as well as ADO); > so it doesn't take a big brain to see that there is absolutely no future > there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the > only difference if that some peoples using these don't know it yet. > > The problem is not to know if there is a future or not for DAO and ADO > (there's none for both of them); the problem is to know what's the best > thing to do in the meantime before we can get our hands on a version of > Access with and integrated version to .NET. > > > -- > > David W. Fenton http://www.dfenton.com/> > usenet at dfenton dot com http://www.dfenton.com/DFA/> > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > > |
|
Hi David,
From your post you seem to still have faith in ADP's which gladens my heart
as I have many customers who look to me for design support in this area.
I have one very important customer who has moved to SQL 2005 and I now
understand there are lots of problems associated with this move.
Are you able to advise the best resource for me to study in order to get
fully up-to-speed with what I need to know, e.g I assume I need to move to
Access2007 to be able to do design changes to the 2005 Backend from the ADP
What is your advice?
|
|
=?Utf-8?B?Qm9iIFNuZWRkZW4=?= <bob[ at ]discussions.microsoft.com> wrote
in news:040824FA-676A-4BAD-9893-338EB389174C[ at ]microsoft.com:
[Quoted Text] > 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP
> (Service Pack?)
An ADP is an Access feature, not a SQL Server feature. What I think
you mean is can an A2K3 ADP admin a SQL Server 2005 database. The
answer is, so far as I know, yes, but with some limitations --
features introduced in SQL Server 2005 are not going to be
supported. Access 2000 had this same problem with SQL Server 2000
(which came out after A2K), and so I've always used A2K3 to do
upsizing and an A2K3 ADP for the few tasks I use an ADP for (I use
MDBs with ODBC by default and would never consider embarking on an
ADP project).
> 2 - Should I now convert to Access2007 if the answer to 1 is NO
It depends on what you need, and what features of SQL Server 2005
are supported in A2K7 that is not in A2K3. Keep in mind that SQL
Server 2008 is the current version, so you're still going to be
behind.
> 3 - If clients want ADP's, as mine seem to do, for the low end
> database applications should I be recommending that SQL 2000 is
> retained for such applications
Seems to me that the developer has different needs than the users,
so you should evaluate those separately. For administration and
application building, it's handy to have full support for all the
features of your SQL Server version. For the end users, there is not
necessarily going to be that same need, so an older version may
suffice.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
=?Utf-8?B?Qm9iIFNuZWRkZW4=?= <bob[ at ]discussions.microsoft.com> wrote
in news:90CD95FE-C56E-4965-A3A7-F7717FA9994E[ at ]microsoft.com:
[Quoted Text] > From your post you seem to still have faith in ADP's
I don't know what post of mine you might be reading that would make
you think that. You replied to a post by Aaron Kempf, who believes
that SQL Server is the answer to every problem, include world hunger
and the problems of the US auto industry. He has no credibility on
any issue, including his alleged area of expertise (i.e., SQL
Server).
ADPs are not going to be developed any further my Microsoft. They
come in different flavors with different kinds of problems and
plusses (they changed from version to version, with broken things
fixed in the 2nd iteration, and working things broken in the same
new version).
Microsoft is not recommending ADPs for SQL Server front ends any
longer. They recommend MDBs with ODBC. They do allow that for
certain reporting tasks, and ADP can be more efficient than an
MDB/ODBC setup. But that's the only area that they recommend ADPs as
superior to MDBs.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
news:Xns9B70DBE46C820f99a49ed1d0c49c5bbb2[ at ]74.209.136.95...
[Quoted Text] > =?Utf-8?B?Qm9iIFNuZWRkZW4=?= <bob[ at ]discussions.microsoft.com> wrote
> in news:040824FA-676A-4BAD-9893-338EB389174C[ at ]microsoft.com:
>
>> 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP
>> (Service Pack?)
>
> An ADP is an Access feature, not a SQL Server feature. What I think
> you mean is can an A2K3 ADP admin a SQL Server 2005 database. The
> answer is, so far as I know, yes, but with some limitations --
> features introduced in SQL Server 2005 are not going to be
> supported. Access 2000 had this same problem with SQL Server 2000
> (which came out after A2K), and so I've always used A2K3 to do
> upsizing and an A2K3 ADP for the few tasks I use an ADP for (I use
> MDBs with ODBC by default and would never consider embarking on an
> ADP project).
To be exact, if the OP means to use Acccess2003 ADP to design SQL Server
server object, such as table/view/SP/UDF, then the answer is no, you cannot,
whether you have service pack or not. The ADP fron-end as user app in
Access2003 still runs, but to design server objects, you need Access2007.
>
>> 2 - Should I now convert to Access2007 if the answer to 1 is NO
>
> It depends on what you need, and what features of SQL Server 2005
> are supported in A2K7 that is not in A2K3. Keep in mind that SQL
> Server 2008 is the current version, so you're still going to be
> behind.
If the purpose to manage/design SQL Server2005 database, then yes, you need
Access2007 ADP. If it is ADP user app, then no, you do not need to. Be
aware, to manage/design SQL Server2005 database, one can use SQL Server
Management Studio/Express (latter is free download). However, ADP does
provide some convenient functiinality on this ground, such as copy/paste
server object into the same or different database in the same or different
SQL Server
>
>> 3 - If clients want ADP's, as mine seem to do, for the low end
>> database applications should I be recommending that SQL 2000 is
>> retained for such applications
>
> Seems to me that the developer has different needs than the users,
> so you should evaluate those separately. For administration and
> application building, it's handy to have full support for all the
> features of your SQL Server version. For the end users, there is not
> necessarily going to be that same need, so an older version may
> suffice.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Yes, stick with SQL 2000.
Or move to Access 2007.
I like a lot of things about Access 2007.
But SQL 2000 is still an outstanding platform, and it will be for a
long long long long long time.
-Aaron
On Dec 10, 11:53 am, Bob Snedden <b...[ at ]discussions.microsoft.com>
wrote:
[Quoted Text] > Dear Sylvain, > > I seem to have come into the middle of a debate about ADP/Access/COM/DCOM > and I wish I could give a considered opinion however:- > > I am a hard working database designer, working for myself and I sense my > livelihood is threatened. Would you be so kind as to answer the following Q's > > 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP (Service > Pack?) > 2 - Should I now convert to Access2007 if the answer to 1 is NO > 3 - If clients want ADP's, as mine seem to do, for the low end database > applications should I be recommending that SQL 2000 is retained for such > applications > > Thank you > -- > Bob Snedden, MCT, MCSD.Net > > "Sylvain Lafontaine" wrote: > > "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid> wrote in message > >news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98... > > > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > > > please)> wrote innews:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: > > > >> It's hard to believe that MS itself is taking Access seriously > > >> when there is not even any certification for it. > > > > I think your point of view is belied by the actions of the Access > > > development team in the recent time frame. Access has a new life > > > both as end-user tool and as developer platform, precisely because > > > of the decisions made in preparation for Access 2007. > > > > Seems to me that MS has almost returned to the point of view about > > > Access that it had c. Office 95/97, where they were pushing Office > > > as a development platform for small and medium-sized businesses. MS > > > went way, way off track with Office 2000 and Access 2000, in my > > > opinion, and it's taken them this long to get back to the right > > > path. > > > > In my opinion, ADPs were a bad idea based on stupid prejudices > > > rather than technical merit/need, and not really a > > > properly-implemented development platform. The development of ADPs > > > sapped resources that should have gone into the core Access > > > application. The fact that ADPs really are dead now (thankfully) > > > just points out the waste of resources. How much better Access could > > > have been for all users if they'd not been led down the garden path > > > by the crazy Enterprise development ideas that mostly came from > > > irrational fear of Jet. > > > Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, VB6, > > etc., are all technologies based on COM/DCOM and MS is in the process of > > killing all technologies based on these because you cannot make real object > > oriented programming with COM/DCOM; only some sort of simulation; unlike > > ..NET which has been designed as an object oriented programming platform from > > the ground up. > > > First, they have killed DNA (Distributed Network Architecture) before it got > > even the chance of getting out of the laboratoray; then their next target > > has been VB6 as well as a lot of smaller associated technologies like ADO, > > VBScript, ASP Classic; etc. Did you really think that after having killed > > these very big pieces of development platforms that were VB6, ASP Classic > > and VBScript, that MS would be giving some serious toughts about keeeping > > VBA and DAO in the long term? > > > I don't really understand how you can say that Access 2007 has got a new > > life as a development platform when practically all the technological > > development that have been made these last years are based on .NET and the > > only thing that Access got was these small bones about Sharepoint; which, by > > the way, are totally useless for anyone using SQL-Server as the backend.. > > > They don't give a s**t about the technical merit/need of ADO vs DAO; all > > they want is to get rid of COM/DCOM in the fatest way; so they are killing > > these littles bunnies one after the other and it shouldn't take to long > > before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally > > absurd for anyone entering the field to learn VBA and DAO (as well as ADO); > > so it doesn't take a big brain to see that there is absolutely no future > > there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the > > only difference if that some peoples using these don't know it yet. > > > The problem is not to know if there is a future or not for DAO and ADO > > (there's none for both of them); the problem is to know what's the best > > thing to do in the meantime before we can get our hands on a version of > > Access with and integrated version to .NET. > > > > -- > > > David W. Fenton http://www.dfenton..com/> > > usenet at dfenton dot com http://www.dfenton.com/DFA/> > > -- > > Sylvain Lafontaine, ing. > > MVP - Technologies Virtual-PC > > E-mail: sylvain aei ca (fill the blanks, no spam please)
|
|
Sorry for the delay; I had to give some rest to my wrist because of pain and
I forgot somehow to keep an eye on all these threads.
[Quoted Text] > 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP
> (Service
> Pack?)
By design change, do you mean to the ADP file itself or the SQL-Server? For
the ADP file or the users using it, there is no problem; however, to change
the tables/views/SP/functions on the SQL-Server 2005; you will have to use
the SQL-Server Management Studio. I don't see why this could be a serious
problem.
> 2 - Should I now convert to Access2007 if the answer to 1 is NO
There are some unrelated problems to ADP in Access 2007 such as the loss of
the setting of individual printers for the reports or the ribbon bat. If
you want to use ADP, there is no advantage of using 2007 - excerpt maybe for
the free availability of the runtime - but there are some disadvantages
related to Access 2007 itself, not to ADP. Unless you want to use the
runtime or the sync service available with Windows Azure, you will see some
advantages to keep Access 2003 instead of switching to 2007 but there are
not stopping show. If you want to use the syncing service, it's possibly
better to use A2007 but I did not really make any test on this.
> 3 - If clients want ADP's, as mine seem to do, for the low end database
> applications should I be recommending that SQL 2000 is retained for such
> applications
I don't see why, unless you want your user to bring changes to the database
themselves using Access. Knowing that's easier to optimize a SP using
SQL-2005 or - even better - SQL-2008; I would not recommend to keep SQL-2000
if you can switch to 2005 or 2008.
Happy new year 2009!
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Bob Snedden" <bob[ at ]discussions.microsoft.com> wrote in message
news:040824FA-676A-4BAD-9893-338EB389174C[ at ]microsoft.com...
> Dear Sylvain,
>
> I seem to have come into the middle of a debate about ADP/Access/COM/DCOM
> and I wish I could give a considered opinion however:-
>
> I am a hard working database designer, working for myself and I sense my
> livelihood is threatened. Would you be so kind as to answer the following
> Q's
>
> 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP
> (Service
> Pack?)
> 2 - Should I now convert to Access2007 if the answer to 1 is NO
> 3 - If clients want ADP's, as mine seem to do, for the low end database
> applications should I be recommending that SQL 2000 is retained for such
> applications
>
> Thank you
> --
> Bob Snedden, MCT, MCSD.Net
>
>
> "Sylvain Lafontaine" wrote:
>
>> "David W. Fenton" <XXXusenet[ at ]dfenton.com.invalid> wrote in message
>> news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98...
>> > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam
>> > please)> wrote in news:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl:
>> >
>> >> It's hard to believe that MS itself is taking Access seriously
>> >> when there is not even any certification for it.
>> >
>> > I think your point of view is belied by the actions of the Access
>> > development team in the recent time frame. Access has a new life
>> > both as end-user tool and as developer platform, precisely because
>> > of the decisions made in preparation for Access 2007.
>> >
>> > Seems to me that MS has almost returned to the point of view about
>> > Access that it had c. Office 95/97, where they were pushing Office
>> > as a development platform for small and medium-sized businesses. MS
>> > went way, way off track with Office 2000 and Access 2000, in my
>> > opinion, and it's taken them this long to get back to the right
>> > path.
>> >
>> > In my opinion, ADPs were a bad idea based on stupid prejudices
>> > rather than technical merit/need, and not really a
>> > properly-implemented development platform. The development of ADPs
>> > sapped resources that should have gone into the core Access
>> > application. The fact that ADPs really are dead now (thankfully)
>> > just points out the waste of resources. How much better Access could
>> > have been for all users if they'd not been led down the garden path
>> > by the crazy Enterprise development ideas that mostly came from
>> > irrational fear of Jet.
>>
>> Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript,
>> VB6,
>> etc., are all technologies based on COM/DCOM and MS is in the process of
>> killing all technologies based on these because you cannot make real
>> object
>> oriented programming with COM/DCOM; only some sort of simulation; unlike
>> ..NET which has been designed as an object oriented programming platform
>> from
>> the ground up.
>>
>> First, they have killed DNA (Distributed Network Architecture) before it
>> got
>> even the chance of getting out of the laboratoray; then their next target
>> has been VB6 as well as a lot of smaller associated technologies like
>> ADO,
>> VBScript, ASP Classic; etc. Did you really think that after having
>> killed
>> these very big pieces of development platforms that were VB6, ASP Classic
>> and VBScript, that MS would be giving some serious toughts about keeeping
>> VBA and DAO in the long term?
>>
>> I don't really understand how you can say that Access 2007 has got a new
>> life as a development platform when practically all the technological
>> development that have been made these last years are based on .NET and
>> the
>> only thing that Access got was these small bones about Sharepoint; which,
>> by
>> the way, are totally useless for anyone using SQL-Server as the backend.
>>
>> They don't give a s**t about the technical merit/need of ADO vs DAO; all
>> they want is to get rid of COM/DCOM in the fatest way; so they are
>> killing
>> these littles bunnies one after the other and it shouldn't take to long
>> before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally
>> absurd for anyone entering the field to learn VBA and DAO (as well as
>> ADO);
>> so it doesn't take a big brain to see that there is absolutely no future
>> there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the
>> only difference if that some peoples using these don't know it yet.
>>
>> The problem is not to know if there is a future or not for DAO and ADO
>> (there's none for both of them); the problem is to know what's the best
>> thing to do in the meantime before we can get our hands on a version of
>> Access with and integrated version to .NET.
>>
>> > --
>> > David W. Fenton http://www.dfenton.com/
>> > usenet at dfenton dot com http://www.dfenton.com/DFA/
>>
>> --
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>>
|
|
Sylvain;
I've had some problems getting SQL 2008 to work, maybe it's related to
high instance count--
have you gotten ADP working with SQL 2008?
-Aaron
On Dec 28, 6:37 pm, "Sylvain Lafontaine" <sylvain aei ca (fill the
blanks, no spam please)> wrote:
[Quoted Text] > Sorry for the delay; I had to give some rest to my wrist because of pain and > I forgot somehow to keep an eye on all these threads. > > > 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP > > (Service > > Pack?) > > By design change, do you mean to the ADP file itself or the SQL-Server? For > the ADP file or the users using it, there is no problem; however, to change > the tables/views/SP/functions on the SQL-Server 2005; you will have to use > the SQL-Server Management Studio. I don't see why this could be a serious > problem. > > > 2 - Should I now convert to Access2007 if the answer to 1 is NO > > There are some unrelated problems to ADP in Access 2007 such as the loss of > the setting of individual printers for the reports or the ribbon bat. If > you want to use ADP, there is no advantage of using 2007 - excerpt maybe for > the free availability of the runtime - but there are some disadvantages > related to Access 2007 itself, not to ADP. Unless you want to use the > runtime or the sync service available with Windows Azure, you will see some > advantages to keep Access 2003 instead of switching to 2007 but there are > not stopping show. If you want to use the syncing service, it's possibly > better to use A2007 but I did not really make any test on this. > > > 3 - If clients want ADP's, as mine seem to do, for the low end database > > applications should I be recommending that SQL 2000 is retained for such > > applications > > I don't see why, unless you want your user to bring changes to the database > themselves using Access. Knowing that's easier to optimize a SP using > SQL-2005 or - even better - SQL-2008; I would not recommend to keep SQL-2000 > if you can switch to 2005 or 2008. > > Happy new year 2009! > > -- > Sylvain Lafontaine, ing. > MVP - Technologies Virtual-PC > E-mail: sylvain aei ca (fill the blanks, no spam please) > > "Bob Snedden" <b...[ at ]discussions.microsoft.com> wrote in message > > news:040824FA-676A-4BAD-9893-338EB389174C[ at ]microsoft.com... > > > > > Dear Sylvain, > > > I seem to have come into the middle of a debate about ADP/Access/COM/DCOM > > and I wish I could give a considered opinion however:- > > > I am a hard working database designer, working for myself and I sense my > > livelihood is threatened. Would you be so kind as to answer the following > > Q's > > > 1 - Can I do design changes in Access 2003 to a SQL 2005 based ADP > > (Service > > Pack?) > > 2 - Should I now convert to Access2007 if the answer to 1 is NO > > 3 - If clients want ADP's, as mine seem to do, for the low end database > > applications should I be recommending that SQL 2000 is retained for such > > applications > > > Thank you > > -- > > Bob Snedden, MCT, MCSD.Net > > > "Sylvain Lafontaine" wrote: > > >> "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid> wrote in message > >>news:Xns9B5CE2571CAD6f99a49ed1d0c49c5bbb2[ at ]74.209.136.98... > >> > "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam > >> > please)> wrote innews:eppt20mSJHA.1148[ at ]TK2MSFTNGP05.phx.gbl: > > >> >> It's hard to believe that MS itself is taking Access seriously > >> >> when there is not even any certification for it. > > >> > I think your point of view is belied by the actions of the Access > >> > development team in the recent time frame. Access has a new life > >> > both as end-user tool and as developer platform, precisely because > >> > of the decisions made in preparation for Access 2007. > > >> > Seems to me that MS has almost returned to the point of view about > >> > Access that it had c. Office 95/97, where they were pushing Office > >> > as a development platform for small and medium-sized businesses. MS > >> > went way, way off track with Office 2000 and Access 2000, in my > >> > opinion, and it's taken them this long to get back to the right > >> > path. > > >> > In my opinion, ADPs were a bad idea based on stupid prejudices > >> > rather than technical merit/need, and not really a > >> > properly-implemented development platform. The development of ADPs > >> > sapped resources that should have gone into the core Access > >> > application. The fact that ADPs really are dead now (thankfully) > >> > just points out the waste of resources. How much better Access could > >> > have been for all users if they'd not been led down the garden path > >> > by the crazy Enterprise development ideas that mostly came from > >> > irrational fear of Jet. > > >> Nice talk but totally beside the point. ADO (and ADP), VBA, VBScript, > >> VB6, > >> etc., are all technologies based on COM/DCOM and MS is in the process of > >> killing all technologies based on these because you cannot make real > >> object > >> oriented programming with COM/DCOM; only some sort of simulation; unlike > >> ..NET which has been designed as an object oriented programming platform > >> from > >> the ground up. > > >> First, they have killed DNA (Distributed Network Architecture) before it > >> got > >> even the chance of getting out of the laboratoray; then their next target > >> has been VB6 as well as a lot of smaller associated technologies like > >> ADO, > >> VBScript, ASP Classic; etc. Did you really think that after having > >> killed > >> these very big pieces of development platforms that were VB6, ASP Classic > >> and VBScript, that MS would be giving some serious toughts about keeeping > >> VBA and DAO in the long term? > > >> I don't really understand how you can say that Access 2007 has got a new > >> life as a development platform when practically all the technological > >> development that have been made these last years are based on .NET and > >> the > >> only thing that Access got was these small bones about Sharepoint; which, > >> by > >> the way, are totally useless for anyone using SQL-Server as the backend. > > >> They don't give a s**t about the technical merit/need of ADO vs DAO; all > >> they want is to get rid of COM/DCOM in the fatest way; so they are > >> killing > >> these littles bunnies one after the other and it shouldn't take to long > >> before it's the turn of DAO and VBA. Now that VB6 is dead, it's totally > >> absurd for anyone entering the field to learn VBA and DAO (as well as > >> ADO); > >> so it doesn't take a big brain to see that there is absolutely no future > >> there; whatever you might say. Like ADP; JET, DAO and VBA are dead, the > >> only difference if that some peoples using these don't know it yet. > > >> The problem is not to know if there is a future or not for DAO and ADO > >> (there's none for both of them); the problem is to know what's the best > >> thing to do in the meantime before we can get our hands on a version of > >> Access with and integrated version to .NET. > > >> > -- > >> > David W. Fenton http://www.dfenton.com/> >> > usenet at dfenton dot com http://www.dfenton.com/DFA/> > >> -- > >> Sylvain Lafontaine, ing. > >> MVP - Technologies Virtual-PC > >> E-mail: sylvain aei ca (fill the blanks, no spam please)- Hide quoted text - > > - Show quoted text -
|
|
|