Martin Reid
mwp.reid at qub.ac.uk
Mon May 11 10:15:59 CDT 2009
John I would guess it will be the same as for the current version. Martin Martin WP Reid Information Services Queen's University Riddel Hall 185 Stranmillis Road Belfast BT9 5EE Tel : 02890974465 Email : mwp.reid at qub.ac.uk ________________________________________ From: accessd-bounces at databaseadvisors.com [accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby [jwcolby at colbyconsulting.com] Sent: 11 May 2009 16:08 To: Access Developers discussion and problem solving Subject: Re: [AccessD] [Accessd] Record Source for Reports Using SQL Db Backend - best practice This is full support including the ability to create and edit stored procedures etc? John W. Colby www.ColbyConsulting.com Martin Reid wrote: > 2007 supports then and I would say its a safe bet but not 100% that another version should. > > Martin > > > Martin WP Reid > Information Services > Queen's University > Riddel Hall > 185 Stranmillis Road > Belfast > BT9 5EE > Tel : 02890974465 > Email : mwp.reid at qub.ac.uk > ________________________________________ > From: accessd-bounces at databaseadvisors.com [accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby [jwcolby at colbyconsulting.com] > Sent: 11 May 2009 12:25 > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] [Accessd] Record Source for Reports Using SQL Db Backend - best practice > > How long did Microsoft support projects? Through 2003? And what happens to a project when you hit > the version where it is no longer supported? Does Access refuse to open it or does the SQL Server > management stuff built in to the project just go away but the rest of the application continues to > function? > > John W. Colby > www.ColbyConsulting.com > > > Anita Smith wrote: >> Borge, >> I mainly use SQL as back end to Access these days. This is my approach: >> 1. Use an Access Project - connected to an SQL Server database using >> "File/Connection" >> 2. Use Stored Procedures as Form and Report Recordsources >> 3. Filter the Forms/Reports by using the [Input Parameter] property - this >> parameter is passed to the stored procedure that the form/report is based on >> thereby giving you a perfect filter. >> >> Example: >> Form: frmCustomer >> Stored Procedure: spCustomers is set as the recordsource >> Procedure spCustomers (@CustomerID int) >> as >> Select * FROM Customers WHERE CustomerID = >> @CustomerID >> >> frmCustomer has the Input Parameter property set to =CurrCust() >> >> CurrCust is a property I set before just before i open the Customer Form. >> When frmCustomers open it will pass the input parameter CurrCust() to the >> stored procedure and the form will be filtered to 1 customer only. >> >> Hope this helps a bit. >> >> Anita Smith >> >> >> >> >> >> >> >> >> Anita Smith >> On Mon, May 11, 2009 at 11:43 AM, Borge Hansen <pcs.accessd at gmail.com>wrote: >> >>> Hi All, >>> >>> The last year and a half or so I have learnt more and more about SQL Db and >>> working with Access FE against SQL BE. >>> >>> I've started using ADO recordset returned from SQL as record source for >>> combo boxes, list boxes and view forms. >>> >>> Recently I started re-working some Reports on an existing application made >>> to run against SQL db that I've taken over maintenance for. >>> >>> These reports run sort of OK as they are - using existing Access queries >>> against ODBC linked tables. >>> >>> But: >>> For example one report use as record source an SQL string on one table with >>> no criteria filter. >>> >>> The filter is placed on opening of the report, like this example: >>> >>> DoCmd.OpenReport "rptAuditRollBook", acViewPreview, , "[ChildID]='" & >>> Me.subfrmChildDetails.Form.ChildID & "'" >>> >>> Is that a good practice - in regards to multi user setup and network >>> traffic? >>> >>> I've read somewhere that Access in retrieving query results not necessarily >>> brings across from the network store all of the columns in the table(s) but >>> only the indexes it requires in order filter out the query result, which is >>> then brought across the network to the FrontEnd. >>> >>> With a docmd statement as the above, does it work as if the filter was part >>> of the report record source SQL Access query string - or does the report >>> open, then pull in all records based on the Access query string, then >>> filters the query result before displaying ??? >>> >>> If it's the latter, wouldn't it be better to build the record source query >>> on the fly - so that only the subset of records are brought across the >>> network and displayed ?? >>> >>> Further, how can we best utilise the SQL Db to provide only subset of data >>> for reports? >>> >>> I've tried to use as record source for a report an ADO record set created >>> by >>> the SQL Db and served to the Frontend - but that doesn't appear to work for >>> reports. >>> >>> Have I missed something here, or can you people confirm that this is the >>> case: as record source for reports with SQL Db as backend we can only use >>> ODBC linked tables and access queries based on ODBC linked tables ??? >>> >>> regards >>> borge >>> -- >>> AccessD mailing list >>> AccessD at databaseadvisors.com >>> http://databaseadvisors.com/mailman/listinfo/accessd >>> Website: http://www.databaseadvisors.com >>> > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com