SIR,

Actually i am working in delhi police department and at local level we maintain data on crime of our district by making small software with many constraints during entry.

  as we have ..you can say constable who dont know computer at all). (at first i taught them basic computer then they get able to feed data as required.). I have made small software in access and  they feed data on regular basis regarding crime.

thereafter through pivot we analyse very easily.

For them to bring data on every now and then to excel and then analysis is cumbersome. earlier they just open drag and drop field or just open pivot to produce analysis .

whole advantage of access is in pivot view. which make it different from other.

please bring it back.
please bring it back in new version

Access returns an incorrect record ID when a form is bound to an SQL Server table that has an 'insert trigger' that inserts a record into 'another' table. The record ID returned is actually the record ID of the trigger inserted record into the 'other' table. This is because Access calls SQL Server for @@IDENTITY rather than SCOPE_IDENTITY() when inserting a new record. This particularly affects SQL Server tables that are 'replicated' as these tables have an MS shipped 'insert trigger' on the table for use in replication. We have an MS Support Case # 23043471 where we have had no resolution ...

Currently, if an existing INSERT INTO query has a problem with an underlying query (if there is an error due to a renamed supporting query or table name, for example), the Query Editor inserts new "phantom alias names" into the QueryDef for each column.
So, the resulting SQL looks sort of like this:
INSERT INTO MyTable (ColA, ColB, ColC...)
SELECT MyDerivedColA as Expr1, MyColB as Expr2, MyDerivedColC as Expr3…
FROM (from clause with some underlying table/query naming error here)...

My request is that since the Query editor is "smart enough" to introduce those "Expr#" Alias labels when needed due to errors, IT ALSO NEEDS TO BE SMART ENOUGH TO REMOVE THEM when they are no longer needed (i.e. when the underlying query/table naming error is resolved, and the "Expr#" labels only introduce unneeded confusion/obfuscation)!

Once we "cure" the underlying dependent query/table name issue, IF all the SOURCE column names (once again) MATCH the TARGET column names, Have the Query Editor AUTOMATICALLY REMOVE any of the "Expr#:" alias column names labels it finds.

This is my wishlist request.

Since your Access/Office Roadmap now has an alternative SQL Editor on the list, I would like to renew this request, because once we can actually edit SQL with some REALLY IMPROVED tools and can care about SQL formatting and whitespace (and maybe SQL Comments too?), this issue will drive some folks absolutely NUTS when their SQL gets "messed up" with these EXPR# alias names unexpectedly.

Given the typical Dev/Test/Prod development staging methodologies, and the great ease by which changes to database objects (especially "supporting"-type changes like adding indexes to existing tables) can occur in a software development cycle, it would be very beneficial to allow the built-in Access Table, Query, Form, and Report designers to save the "state" of the overall object, and at "Save"-time offer an option to Generate VBA and/or SQL scripts that can help to facilitate the (re-)deployment of the new changes to partnering databases (migrate the changes from Test back to Dev or Prod copies of a database, for example).
Being able to (optionally) designate a database's SDLC Stage via pre-defined database properties and adding some supporting code appropriate to Dev/Test/Prod stages of a database file would be of great help as well.
Adding things like:
Having Access disallow dropping forms/queries/reports/code modules into DEV modes in a database marked as Production-level;
Adding additional prompts "This Database is designated as a TESTing database - Are You Sure?" before entering DEV modes for database objects in designated TEST DBs (and doing so even more emphatically when saving changes - offering the scripting options by default as part of the save operation);
Only designated DEV versions of the database files would have the same level of ease-of-use for editing operations we enjoy by default today.