Microsoft+Access+2007+integration+with+SQL+Server

Previous editions of Microsoft Office have provided some degree of connectivity between Office applications and third-party data sources. There has also been a fair degree of integration with SQL Server — which, I guess, counts as a first-party data source. But Office 2007 introduces some new features to integrate Office all the more tightly with SQL Server. Those not well-versed in Microsoft Access turn to it as a kind of SQL Server to do quick-and-dirty, single-user database programming. Before the advent of SQL Server 2005 Express Edition, that was about the only way to do such a thing without the expense of a full SQL Server installation. Most organizations that had an Office license had Access as part of the bargain. Databases built in Access alone could be deemed heavily self-limiting; The possibility was there for it to only allow one concurrent user at a time per database and not have the more powerful data analysis functions of SQL Server. The problem may lie in the fact that it is possible to create some very badly-designed Access databases; Those that were intended to support multiple users were not put together by people who really understood how to do that. The sight of too many bad Access implementatons has turned some people off. The generic answer suggested to them was to upgrade to SQL Server as the backend, rather than to use programming approaches for Access that make multi-user scenarios possible. Using Access as a front end for SQL Server lets you take advantage of the SQL Server data engine, and use Access forms and reports with it. Access 2007 has two ways you can connect to SQL Server data: linking to SQL Server via an MDB file or ACCDB file (the new Access 2007 file format, which takes the place of the MDB file extension), or by creating an Access Data Project (ADP). ADPs are OLE documents that contain front-end presentation items (forms, reports, VBA code, etc.), which are connected to tables and queries in SQL Server.