marc_butler
asked on
Equivalent to QueryDef in ADP
Hi,
I'm currently starting to look at migrating our database to an Access Data Project (adp) from it's current form as an mdb but one of the first stumbling blocks I've come across is that the following code doesn't work in the adp.
Set qd = CurrentDb.QueryDefs("FLTra
qd.sql = sql & " WHERE (([CLAIM.Ref])=" & Ref & ");"
qd.Close
I use it to get the sql statement from an existing query and then alter it to filter for the one reference, mainly when producing letters or reports but at the moment it's just dropping out on the first line.
I've recreated my query in my adp project using a view but I need a way to get the sql statement from the view so I can add the ref and then use the ALTER VIEW syntax.
Any help or better ideas to this problem would be appreciated.
I'm currently starting to look at migrating our database to an Access Data Project (adp) from it's current form as an mdb but one of the first stumbling blocks I've come across is that the following code doesn't work in the adp.
Set qd = CurrentDb.QueryDefs("FLTra
qd.sql = sql & " WHERE (([CLAIM.Ref])=" & Ref & ");"
qd.Close
I use it to get the sql statement from an existing query and then alter it to filter for the one reference, mainly when producing letters or reports but at the moment it's just dropping out on the first line.
I've recreated my query in my adp project using a view but I need a way to get the sql statement from the view so I can add the ref and then use the ALTER VIEW syntax.
Any help or better ideas to this problem would be appreciated.
With adp, the queries reside on server side, and often you don't need them at all. Create sql statement in code by concatenation, then execute it.
sql = "select * from my claim inner join transportations on claim.transport_id = transportations.id where claim.ref = " ref
instructions = currentproject.connection.
It should be noted however that Access works best if you let it do data manipulations by itself, i.e. if you bind forms etc. to sql statements, and let Access run those queries when it wants - rather than run them in code.
sql = "select * from my claim inner join transportations on claim.transport_id = transportations.id where claim.ref = " ref
instructions = currentproject.connection.
It should be noted however that Access works best if you let it do data manipulations by itself, i.e. if you bind forms etc. to sql statements, and let Access run those queries when it wants - rather than run them in code.
I'm guessing that he is doing it to export/attach data to an external destination. I commonly do a query on the fly to attach to an e-mail and then delete it right after.
Just to offer that I'd agree that the manipulation of existing server objects (even when improved upon by switching to creation of temporary server objects - other than actual Temporary objects) is non-ideal for the reasons already stated. You're not operating on local objects anymore - which offers a great deal of convenience, flexability and concurrency.
If you want to describe the process that you're actually performing in all this it will help provide an appropriate overall solution.
I do want to just raise a flag over the earlier "Access works best if you let it do data manipulations by itself".
In that "best" is, of course, a subjective term. :-)
If you feel that Access exists primarily for developing fast (almost prototype only) applications then the binding everything philosphy gives great results. But an application will often involve much more than that - for example running statements in code or performing other operations other than through the UI. (And of course from a performance perspective - allowing full control to have handled through bound forms can be less than the optimal arrangement).
A bound form in an ADP operates with a slightly different mentality anyway.
FWIW I agree that bound forms are probably Access greatest strength (subforms going hand in hand with that).
I personally use them a vast majority of the time - naturally. :-)
Cheers.
If you want to describe the process that you're actually performing in all this it will help provide an appropriate overall solution.
I do want to just raise a flag over the earlier "Access works best if you let it do data manipulations by itself".
In that "best" is, of course, a subjective term. :-)
If you feel that Access exists primarily for developing fast (almost prototype only) applications then the binding everything philosphy gives great results. But an application will often involve much more than that - for example running statements in code or performing other operations other than through the UI. (And of course from a performance perspective - allowing full control to have handled through bound forms can be less than the optimal arrangement).
A bound form in an ADP operates with a slightly different mentality anyway.
FWIW I agree that bound forms are probably Access greatest strength (subforms going hand in hand with that).
I personally use them a vast majority of the time - naturally. :-)
Cheers.
when you open a form or report with DoCmd, you can supply a filter criterion as one of the [optional] parameters.
LPurvis, it's not quite subjective; it's based on years of answering the questions, each beginning with totally unnecessary code that opens separate connection, creates ado command, carefully fills all parameters, then runs the command and finally assigns the recordset to be the recordsource of the form. Certainly, in serious application you will have numerous direct data manipulations, but there's big difference between the philosophy "bind what you can, use ado with the rest" and "ado everything, then bind what you need on the form". Many novices in ADP often don't even know that that difference exists, they immediately step on the 2nd path and begin producing pages of code.
The result of the 1st approach is, naturally, much shorter code, or even no code at all, hence much shorter development cycle and better manageability of the code. Why coding manually what the tool already does? besides, until Access 2003, touching me.recordset resulted in guaranteed crash several manipulations later.
As for the performance - could you give an example where you achieve better performance by un-binding?
The result of the 1st approach is, naturally, much shorter code, or even no code at all, hence much shorter development cycle and better manageability of the code. Why coding manually what the tool already does? besides, until Access 2003, touching me.recordset resulted in guaranteed crash several manipulations later.
As for the performance - could you give an example where you achieve better performance by un-binding?
marc,
Your question aside, I would seriously look at not using an ADP type setup. Instead I would use the old tried and true technique of using a robust backend (ie. SQL Server) and then use linked tables via ODBC to access the data
Why? As of 2007, the ADP feature has been dropped from Access, so your going to be stuck using A2000 or A2003. Neither of those is being updated to work with newer versions of SQL Server. For example, A2003 doesn't play well with SQL Server 2005 up. You end up updating the server side objects in SQL.
Second item is that most of your app will work unchanged. This is a big benefit in my mind as you can move to a robust backend relatively painlessly and move into more of a true client/server setup as time permits (use of pass through queries, stored procedures, etc). Third, it opens the door to using other backends besides SQL Server. With an ADP, you stuck with SQL Server like it or not. Fourth, you can use DAO or ADO (or even mixed).
Note however that by simply using ODBC you *might* see a performance decrease. Most don't, but moving to a client/server type setup does need a bit of a mind shift both in app design and development.
You might find that you need to move a few critical tasks to a pass through query or stored procedure right off. Also true client/server apps typically don't do things like bind a table directly to a form, where in the Access/JET world that is almost always done an even encouraged.
There are many apps that work quite well just with simple ODBC connections. It's easy enough to try and I would do so before continuing with the ADP route.
FWIW,
JimD.
Your question aside, I would seriously look at not using an ADP type setup. Instead I would use the old tried and true technique of using a robust backend (ie. SQL Server) and then use linked tables via ODBC to access the data
Why? As of 2007, the ADP feature has been dropped from Access, so your going to be stuck using A2000 or A2003. Neither of those is being updated to work with newer versions of SQL Server. For example, A2003 doesn't play well with SQL Server 2005 up. You end up updating the server side objects in SQL.
Second item is that most of your app will work unchanged. This is a big benefit in my mind as you can move to a robust backend relatively painlessly and move into more of a true client/server setup as time permits (use of pass through queries, stored procedures, etc). Third, it opens the door to using other backends besides SQL Server. With an ADP, you stuck with SQL Server like it or not. Fourth, you can use DAO or ADO (or even mixed).
Note however that by simply using ODBC you *might* see a performance decrease. Most don't, but moving to a client/server type setup does need a bit of a mind shift both in app design and development.
You might find that you need to move a few critical tasks to a pass through query or stored procedure right off. Also true client/server apps typically don't do things like bind a table directly to a form, where in the Access/JET world that is almost always done an even encouraged.
There are many apps that work quite well just with simple ODBC connections. It's easy enough to try and I would do so before continuing with the ADP route.
FWIW,
JimD.
vadimrapp1, it's hard for me to express just how much I don't want to get into this...
But to at least address some of your points so I've not just ignored them - I'm not fundamentally disagreeing (nor was I in my previous post).
ADP's offer great functionality for implicit use of SQL Server objects. But, for example, I find Input Parameters a little limiting even thought they're great in concept.
I wasn't advocating ADO everything, bind the rest. Just pointing out that there are alternative viewpoints. (I've answered a question or two myself over the years - so I'd still maintain that it's subjective, based on each experts preference).
That Access 2003 was the final stable version we'd been waiting for regarding form recordset operations isn't in dispute. That it's the version to use for that reason and others is pretty much widely accepted still (we'll see just how good 2010 is when it gets pushed and proded properly).
Performance? Really only the old story with Access of implicit commitals. You can bunch up operations into a single hit on the server rather than as a user navigates if it's of benefit.
That and the inevitable refreshing that Access will perform when it deems it required.
(By the way, I'd be talking about truly unbound Vs bound here. Assigning a recordset to a form is still a bound form - merely late bound).
To mention Jim's point about availability of ADPs, they weren't dropped from 2007, they were made more difficult to create though.
They are still fully supported - not depricated at all - but no functionality additions were made. (The same is true for Access 2010 - they're still there).
MS does indeed advocate ACCDB with linked tables now. And there's nothing really wrong with that (especially if you know what you're doing) but we don't listen and follow MS' lead implicitly do we? ;-)
The ability to work with data designers from Access to the SQL Server does indeed require that the version of SQL Server is equal or older than the Access release. (They don't "play nice" in that respect :-). However the data access and operations are unaffected by versions in that way.
I'd agree you'll find the transition a lot simpler by moving to ODBC links rather than the ADO oriented ADP.
(And it's my considered opinion that familiarity with ADO is essentially a pre-requisit for working with ADPs in all but the simplest of applications).
Cheers all!
But to at least address some of your points so I've not just ignored them - I'm not fundamentally disagreeing (nor was I in my previous post).
ADP's offer great functionality for implicit use of SQL Server objects. But, for example, I find Input Parameters a little limiting even thought they're great in concept.
I wasn't advocating ADO everything, bind the rest. Just pointing out that there are alternative viewpoints. (I've answered a question or two myself over the years - so I'd still maintain that it's subjective, based on each experts preference).
That Access 2003 was the final stable version we'd been waiting for regarding form recordset operations isn't in dispute. That it's the version to use for that reason and others is pretty much widely accepted still (we'll see just how good 2010 is when it gets pushed and proded properly).
Performance? Really only the old story with Access of implicit commitals. You can bunch up operations into a single hit on the server rather than as a user navigates if it's of benefit.
That and the inevitable refreshing that Access will perform when it deems it required.
(By the way, I'd be talking about truly unbound Vs bound here. Assigning a recordset to a form is still a bound form - merely late bound).
To mention Jim's point about availability of ADPs, they weren't dropped from 2007, they were made more difficult to create though.
They are still fully supported - not depricated at all - but no functionality additions were made. (The same is true for Access 2010 - they're still there).
MS does indeed advocate ACCDB with linked tables now. And there's nothing really wrong with that (especially if you know what you're doing) but we don't listen and follow MS' lead implicitly do we? ;-)
The ability to work with data designers from Access to the SQL Server does indeed require that the version of SQL Server is equal or older than the Access release. (They don't "play nice" in that respect :-). However the data access and operations are unaffected by versions in that way.
I'd agree you'll find the transition a lot simpler by moving to ODBC links rather than the ADO oriented ADP.
(And it's my considered opinion that familiarity with ADO is essentially a pre-requisit for working with ADPs in all but the simplest of applications).
Cheers all!
<<To mention Jim's point about availability of ADPs, they weren't dropped from 2007, they were made more difficult to create though.
They are still fully supported - not depricated at all - but no functionality additions were made. (The same is true for Access 2010 - they're still there).>>
Wow.. wasn't aware of that. Everything I had heard/read up to the release of A2007 said that ADP's were being dropped and not to expect any changes required for future releases of SQL Server. In fact I know someone who works with the Microsoft team directly and this is the line he's always stated. I've never heard him say otherwise.
Just goes to show you that I've never used A2007<g> and no one has ever corrected me on that either up to this point (which I'm very surprised at as I've stated that numerous times). Very sorry for the mis-information.
<<MS does indeed advocate ACCDB with linked tables now. And there's nothing really wrong with that (especially if you know what you're doing) but we don't listen and follow MS' lead implicitly do we? ;-)>>
yes, if you look in the MSDN article on migration issues for A2000/A2003, Microsoft does not recommend using ADP's, but using a MDB/ACE with linked tables.
Here's the article:
http://technet.microsoft.c
it's about half way down.
Leigh,
I was under the impression though that no changes have been made in the ADP functionaility. So does A2007 play nice with SQL Server 2005, but not 2008?
JimD.
They are still fully supported - not depricated at all - but no functionality additions were made. (The same is true for Access 2010 - they're still there).>>
Wow.. wasn't aware of that. Everything I had heard/read up to the release of A2007 said that ADP's were being dropped and not to expect any changes required for future releases of SQL Server. In fact I know someone who works with the Microsoft team directly and this is the line he's always stated. I've never heard him say otherwise.
Just goes to show you that I've never used A2007<g> and no one has ever corrected me on that either up to this point (which I'm very surprised at as I've stated that numerous times). Very sorry for the mis-information.
<<MS does indeed advocate ACCDB with linked tables now. And there's nothing really wrong with that (especially if you know what you're doing) but we don't listen and follow MS' lead implicitly do we? ;-)>>
yes, if you look in the MSDN article on migration issues for A2000/A2003, Microsoft does not recommend using ADP's, but using a MDB/ACE with linked tables.
Here's the article:
http://technet.microsoft.c
it's about half way down.
Leigh,
I was under the impression though that no changes have been made in the ADP functionaility. So does A2007 play nice with SQL Server 2005, but not 2008?
JimD.
Hi Jim.
>> So does A2007 play nice with SQL Server 2005, but not 2008?
Yes that's right. (Continuing the definition of "play nice" to mean able to read and work in the data designer - data operations and connections are still unaffected by versions).
To be honest (not that I use ADPs much at all for live work) I've never minded that designer issue. I prefer to work on designing with SQL Server objects using its own tools - i.e. Management Studio (even though it runs like a bit of a dog on my old laptop).
MS making the designers work with a version of SQL Server doesn't seem to count per se as changes in functionality - merely fixing/updating existing functionality.
I've not been a fan of 2007 myself (vocally so and in forums).
For me it offered too little (for developers) with too many new issues. But it wasn't the complete picture and the world should be seeing better from 2010.
Cheers.
>> So does A2007 play nice with SQL Server 2005, but not 2008?
Yes that's right. (Continuing the definition of "play nice" to mean able to read and work in the data designer - data operations and connections are still unaffected by versions).
To be honest (not that I use ADPs much at all for live work) I've never minded that designer issue. I prefer to work on designing with SQL Server objects using its own tools - i.e. Management Studio (even though it runs like a bit of a dog on my old laptop).
MS making the designers work with a version of SQL Server doesn't seem to count per se as changes in functionality - merely fixing/updating existing functionality.
I've not been a fan of 2007 myself (vocally so and in forums).
For me it offered too little (for developers) with too many new issues. But it wasn't the complete picture and the world should be seeing better from 2010.
Cheers.
Here's good comment: link
Here's directly from Microsoft:
"They (ADP) will continue to run in 2008 with support for design against SQL 2008--that said, we did very few new features that were specific to ADPs. ADPs continue to be the best option for a class of applications but development efforts likely will continue to focus in areas where the vast majority of our customers use--mdb/accdb."
Here's directly from Microsoft:
"They (ADP) will continue to run in 2008 with support for design against SQL 2008--that said, we did very few new features that were specific to ADPs. ADPs continue to be the best option for a class of applications but development efforts likely will continue to focus in areas where the vast majority of our customers use--mdb/accdb."
"in 2008" - he obviously meant "in 2010".
I don't see that quote in the link when I follow it.
Perhaps it's just the wrong link.
Sylvain is a very knowledgable chap with expertise in several disciplines including Access - but he doesn't speak for MS. ;-)
Perhaps it's just the wrong link.
Sylvain is a very knowledgable chap with expertise in several disciplines including Access - but he doesn't speak for MS. ;-)
That quote is not from Sylvain's post, it's from Microsoft.
I see - they're separate.
Any idea where that MS quote is from then? I've been reluctant to speak too much on that subject but a public quote from MS would alleviate such limitations for me.
Any idea where that MS quote is from then? I've been reluctant to speak too much on that subject but a public quote from MS would alleviate such limitations for me.
> Any idea where that MS quote is from then?
sorry, can't disclose. They are going to make a post to this effect on Access blog (http://blogs.msdn.com/access ). Please don't quote it outside of this thread.
If their future blog post also mentions "vast majority of our customers using mdb/accdb", it will be fun to discuss.
sorry, can't disclose. They are going to make a post to this effect on Access blog (http://blogs.msdn.com/access ). Please don't quote it outside of this thread.
If their future blog post also mentions "vast majority of our customers using mdb/accdb", it will be fun to discuss.
It could be an even simpler solution...
1. if you look at querydef SQL, it is semicolon terminated.
2. The posted code does not remove the semicolon before appending the WHERE clause. If it didn't cause an error, it would surely cause the query parser to ignore everything after the semicolon.
3. Assuming the best case, the snippet should correct this problem.
================
As I already posted, the ability to add selection/filter criteria to the form and report open operations is the best way to operate.
It is NOT a good design to change querydefs in this manner for this purpose.
1. if you look at querydef SQL, it is semicolon terminated.
2. The posted code does not remove the semicolon before appending the WHERE clause. If it didn't cause an error, it would surely cause the query parser to ignore everything after the semicolon.
3. Assuming the best case, the snippet should correct this problem.
================
As I already posted, the ability to add selection/filter criteria to the form and report open operations is the best way to operate.
It is NOT a good design to change querydefs in this manner for this purpose.
Set qd = CurrentDb.QueryDefs("FLTransportInstructions")
strSQL = qd.SQL
strSQL = Left$(strSQL, InStrRev(strSQL, ";")-1)
qd.sql = strSQL & " WHERE (([CLAIM.Ref])=" & Ref & ");"
qd.Close
WOW! And the asker hasn't even posted back yet!
I'm thinking that when the "official" blog post shows up, several of you should collaborate to talk about ADP vs Acc ## & ODBC as an article.
I'm thinking that when the "official" blog post shows up, several of you should collaborate to talk about ADP vs Acc ## & ODBC as an article.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You'll have to convert it to the ADO version and do something along the lines of
--------------------------
SQL = "CREATE VIEW FLTransportInstructions " & _
"AS " & _
"SELECT * FROM CLAIM WHERE (([CLAIM.Ref])=" & Ref & ");"
executeSQL (SQL, CONNStr)
--------------------------
I'm not up on my ADO so I'll ping some other experts to give you some guidance.