Access 15 and SQL Server

Hi, just wanted to ask if there's any plan to bring up to speed the graphics and charts engine in Access, more like the one in Excel. Excel charts are beautiful, but Access charts are... old. Please consider this. Thanks.

I've been waiting for a long time to see an Expression builder tool whilst creating Stored Procedures using an ADP.

The GUI for creating Stored Procedures,Views etc should be more user friendly like its in a .MDB query design grid.

I feel the entire concept of a .ADP should be incorporated in a .MDB or a .ACCDB in the future release where one can directly link to SQL-Server tables like how one did in a .MDB backend.

If a .ACCDB file is being used as a front-end to SQL-Server there should be a facility for creating parameterized stored procedures at the server side. This is a long awaited request which Microsoft has been ignoring.

Lets see how it goes with 2010 then we can still have some more idea's for Version 15.

While a bit off the question, but it would be very great to either upgrade the VBA IDE to have features like in the VS 2010 IDE or add to VBA internal .Net programming.

plus, like VS 2010 began to use WPF that renders on directX, i think that the hole office products should also use it.

1. I would always use SQL Server for the reasons you have given

2. I always use ADP, as this gives better performance than using linked tables; therefore would like to see improvements to this. 3. We are currently using Access2002 with ADP. The functionality is pretty much spot on, but there are some bugs that it would be good to see fixed. Plus bound forms cause a lot of dictionary queries - could this be tuned to reduce network traffic.

4. N/A - we do all SQL Server work from SQL Management Studio and never use the Tables/Queries/Database Diagrams area of the DB window.

Ashok, Gantt charts are available for Access forms:

mymsaccessblog.blogspot.com/.../gantt-chart-using-microsoft-chart.html

1. We use SQL for the same reasons given. 2. We use a an mdb front end and do as much as possible with ADO, ie: loading data into forms and saving data. We have linked views for reports and list boxes/combo boxes. This has worked very well for us so far. I know we don't use SQL to it's full potential but it's really just been a question of taking the time to learn SQL better. We tried ADP at one point but didn't see any real advantage and a loss of some capabilities. If there is a real advantage in performance over what we do. We'd be interested in knowing what it is. I would like to see an improvement in working with linked SQL Tables. Creating the link is a real pain if there are a lot of tables and views in SQL.

3. The wizards for linking tables, refreshing tables, etc. need an update, I link to the same ODBC 98% of the time, do I have to go looking for it every time? When linking to a SQL View, let me type in the name of the view or have the option to only see views rather than having all the tables in the list as well. 4. I'm not real familiar with Stored Procedures but it seems like I have to jump through hoops to use them, along with Pass-Through queries.

5. For the most part I'm happy with the arrangement, I wouldn't mind eliminating the linked views in the lists and reports and use a recordset created with ADO to populate those, that may not be a good solution compared to others. Or maybe I need to make the leap to ADP, I just have the feeling it's the ugly step-child that gets developed after normal Access has been put together and there is always a question of when it will be abandoned. As far as my use goes it's not needed.

1. Support for hierarchical queries (with an improved tree control - perhaps add a nice Wizard to help the user write the query and populate the tree ;)

2. Integration with the new PowerPivot features.

3. SQL Server Design mode (similar concept to 'web design mode') whereby you create your design using Access tables (restricted to SQL compatible data types) and queries are created in SQL compatible syntax. This makes development easier as you only have an accdb file to worry about at this stage. When you come to deploy the system splits the database and creates the SQL back-end for you.

Access:

1. Enlarge database size to 100GB... at least.

2. Don't slow down Access if there are more than 5 users connected to the same database.

3. Access is very slow when updated FE is "re-linking" to the existing BE DB while other users work with the same DB. SQL:

1. More support for non-Microsoft SQL-servers, please.

2. Is there any way to make PassThrough queries editable so that we can use them in (sub)forms?

4. 100% compliance of data types between SQL Server and Access. Easy import/export projects (databases) from Access to SQL and back. Make Access completely based on SQL (or SQL Compact).

起来 向往着自由的人们 把你们的恐惧化成你们新的力量 人们的自尊到了被践踏的程度 每个人被迫着发出愤怒的吼声 起来. 起来. 起来. 我们全力顽抗 顶着敌人的压迫 前进. 顶着敌人的压迫(渴望光明的人们) 坚强. 愤怒. 不懦弱.

Looks like that MS Access and SQL are very popular in this Blog. I thought that MS had stopped support-development for ADP and the way to go to share databases would be Sharepoint 2010. Anyway, WEBFORMS for SQL express and Link table technology without ODBC would be good features for the next version of Ms Access. Joao Santos.

Here's an idea that I hope will catch on! I have made an MDB application linked to an SQL backend. The user runs a script to copy the MDB to a local location, so that the original is not in any way modified. In this way I can make changes to the original MDB while others are using their local copy. A better solution would be to have access run in a "front end mode" in which no changes are made to the underlying MDB. The admin user could then right click on the file to open it in "design mode" and commit the design changes when complete. The front-end mode would have different start-up options from the design mode. This would save a huge amount of time when making small iterative changes to the front-end of a multi-user database.

These special front-end files could alternatively have a different extension eg mdbf (for frontend) It should also be easier to package the application in an installer containing:

1. The access MDB/MDE/ACCDB + runtime

2. The SQL backend

3. Options to connect the front-end to an already existing SQL backend (changing the linked tables accordingly)

HI, I would like to second Leos call,

Can something PLEASE!!!! be done to update MSGraph. It seems to be the little orphan that has been left sitting in the corner since about 1994. A fresher Aero look, Drill through ability Zoom In/Out. The current Graphing is just embarrassing! talk about Windows 95 look in 2010 Oh and since we are making requests... A Better Tree-view control! with wizard Back onto SQL;

Pretty much what everyone else has said above, Bypass ODBC Please, Use native Driver, Publish Queries/tables to SQL, Better integration with SQL Management studio, Query Analyzer. ability to convert Access queries with IIF's Date syntax etc etc to the SQL Syntax. Be able to convert Functions to SQL Functions etc

Thanks

We use access .mde/.adp since access97/sqlserver 6.5 and have 100 GB SQL Server database behind it. Here are points, that disappoint me very much:

- Report editor does not have Zooming function. We use reports to print Labels, some reports are so complicated, that on label that is 1x1 cm we have over 20 controls placed. You have a chance to change something, if you know what you need, and pick the right control in Properties editor in the list. "Visual" Editing is not possible. I wish I could Zoom-in that lable to my whole 24" Screen and do real WYSIWYG Editing.

- Old Common controls library. Buy DevExpress controls, and integrate them into Access :)

- Old-styled VBA Editor

- no Native .NET support in Access (Word and Excel have it since 2007)

- scalability: create a native Access Server, which integrates better with access and is easier to use/install than SQL-Server. - easier development: get rid of the mdb-container. every form/report/module/table/index/schema should be placed in its own file -> version control, subdirectories for big projects. pack them together for deployment. open xml based file formats for forms/reports (code generation, external tools). - up to date ui: i have seen access dialog boxes in acc2007 with a list of more than thousand entries but a height of 1 inch. - record handlers: like database triggers, but just a simple VB-class bound to a table with event handlers (BeforeUpdate, BeforeDelete ...). - rich text field type

- bigger varchar-fields (instead of having to use unstable memo-fields)