We have some Web services (written in .NET WCF) that currently hit a Microsoft SQL Server database to retrieve/update data. We now have a requirement to also retrieve/update data from a Microsoft Access database. The Access database is currently being used by a number of legacy systems so we can't really convert it to a Microsoft SQL server database - we're stuck with an Access database.
My question is: Is there a way we can communicate with the Access database "through" Microsoft SQL Server (so that we can issue T-SQL commands to it and MS SQL Server would handle all the underlying mapping to query the Access database?) Or is it better to just communicate with the Access database via ADO.NET by exposing the location of the Access database on a network share? Does anyone have any suggestions we could try out?
Thanks all.
What about keeping the legacy access application, but moving the tables and data out of the Access application?
Access is makes a great front end to SQL server. When you build an application with Access, just like most other development tools, you have to choose what data engine and database system you going to use with Access. Access have native support built in for the JET data engine (now called ACE). Access has native support built in for SQL server. And access 2010 not only has support built in for using SharePoint, but also SQL Auzure.
So you could consider moving the data that Access now uses to SQL server, and very little if any changes need be made to the access application. So Access application function happy if the tables are in a file (mdb or accdb file), or server based like SQL server, and in fact for tables that reside on SharePoint, Access is in fact using web services to update that data on SharePoint. However, in all cases, the standard code, forms, VBA code and even the SQL used need not be changed.
So I don't the solution here is to attempt to attach SQL server to some "file" sitting in a folder but simply have Access attached to the SQL server to update the tables, and thsu no need to "transfer" data between the systems would exist anymore.
Use a linked server:
A linked server allows for access to distributed, heterogeneous queries against OLE DB data sources. After a linked server is created by using sp_addlinkedserver, distributed queries can be run against this server.
If you're only ever running on a 32-bit platform:
EXEC sp_addlinkedserver
#server = N'SEATTLE Mktg',
#provider = N'Microsoft.Jet.OLEDB.4.0',
#srvproduct = N'OLE DB Provider for Jet',
#datasrc = N'C:\MSOffice\Access\Samples\Northwind.mdb';
Or if you have to worry about 64-bit as well:
EXEC sp_addlinkedserver
#server = N'SEATTLE Mktg',
#provider = N'Microsoft.ACE.OLEDB.12.0',
#srvproduct = N'OLE DB Provider for ACE',
#datasrc = N'C:\MSOffice\Access\Samples\Northwind.accdb';
Related
I need to lock down access to a linked server object in MSSQL server.
I am building views on a host database, from which, I query to populate a staging table on my warehouse server. I am using Data Tools/SSIS to extract the view data. To simplify the SSIS package, I am using the OPENQUERYsyntax to query the linked server object that exists on my warehouse server, and connects to other SQL servers, Oracle servers, etc., through linked server objects.
To provide access to the linked servers, I have set up a local SQL login on the host db that has read access, then I use 'Be made using this security context:' and pass the local SQL login. That works just fine.
I realize now that I have a problem: any user with warehouse access can query the linked server object because of that stashed security context! I don't want that! I do need folks who should have access to be able to query (so I can write my SSIS packages), as well as the SQL Server Agent service account to have access so when the SQL Server Agent job runs as that user that it can successfully query the linked server.
I believe that the key to locking down query access to the linked server object is somewhere in the 'Local server login to remote server login mappings', but I'm having a hard time figuring that out. When I try to add for instance NT SERVICE\SQLAgent mapped to the local login with access, then save, I hit 'Login failed for 'NT AUTHORITY\ANONYMOUS LOGON' when saving.
Any ideas on how I can allow a security groups that have access, and SQL Server Agent service account to query the linked server, but not the rest of people with warehouse access?
This is known as the 'double hop' problem
(https://blogs.technet.microsoft.com/askds/2008/06/13/understanding-kerberos-double-hop/)
and to get rid of the Anonymous login error you would have to properly set up Kerberos pass-through authentication;
https://blogs.msdn.microsoft.com/farukcelik/2008/01/02/how-to-set-up-a-kerberos-authentication-scenario-with-sql-server-linked-servers/
https://www.databasejournal.com/features/mssql/article.php/3696506/Setting-Up-Delegation-for-Linked-Servers.htm
However this is quite involved - you mention that to 'simplify' the SSIS package you use a linked server, however SSIS solves exactly this problem... Why don't you just use SSIS to copy the data from the other server to avoid using a linked server?
I have a scheduling software that has a database of clients, client pets, pets grooming styles, appointments and invoices.
The generic reports that are given with the software are not giving me the information that I need to go. Support from the software company is telling me to use Access to build the reports that I require.
I am not seeing how to connect to the software's DB to use in Access to generate my custom reports.
Any help or links to the information for this would be greatly appreciated.
Thanks in advance everybody
One of MS Access' unique features is connecting to external RDBMs' ( SQL Server, Oracle, Postgres, MySQL, SQLite) in complement to its default Jet/ACE SQL Engine. In fact, Access can connect to any other ODBC-compliant system even Quickbooks or your software assuming it has an ODBC API.
An .MDF is a SQL Server main database file but usually you do not connect directly to the file but the server instance. Most likely, you are required to connect Access to the SQL Server database the software sits on. In fact, you will be doing what the software does: connect to a backend database. No software or web/mobile app is without a database or data store of some kind.
MS Access backend setup is very easy with many online tutorials:
Find the SQL Server instance and all needed credentials (server address or host, port, schema, user, password).
Be sure to have an installed ODBC Driver (usually already available if SQL Server is installed) or check if software has a pre-defined DSN. Free MSSQL ODBC downloads are available online. Open odbcad32.exe to see current computer driver/DSN installs.
In a saved Access .accdb/.mdb database, under External Data tab in MSAccess.exe, click ODBC database (globe icon) where you walk through a wizard to connect to aforementioned Driver or DSN (machine or user). You can either import tables or link live tables which upon successful connection will prompt you to select the database tables.
From there you can use linked tables like any other local table within MS Access including forms, reports, macros, and modules.
In fact, knowing the ODBC connection you can work in most programming languages that maintain database APIs including Python, PHP, R, Perl, Java, C#, VB, even your everyday MS Excel to interact with scheduling software's data.
I will try make this question clear as possible.
I have not found solid help on google really or anywhere else.
To make it short and simple.
I have a vb.net project in which i want two databases.
A local access database which must be created within the project at design, meaning at publishing and then installing this program to another user it must automatically create an acccess database on that user's computer,sync it with a SQL remote server and copy all records at first time run to the access database. The access database is used when my worker is on site and there is no connection to the remote SQL Server database.
Upon achieving connection to the remote SQL Server database at e.g. the office, the access db must update the SQL server database,compare the two databases and copy any new records in the local (Access Db) to the remote sql server and vice versa.
Hope this is clear enough?
Thanks for any help
We have two Sql 2008 R2 database. First and main one is on-premise which is used by our stock management and accounting systems.
The second is for our web site and it is on a 3th party hosting firm and that database is updated manually by a standard XML file operation
(creating XML from on-premise database, sending it to web server, reading from XML file & insert/update/delete web database)
we need to get rid of that manual XML operation and sync that two databases automatically, but problem is our hosting firm does not allow "Replication" or "Linked Server" facilities on their "Sql Server" system. That's way we can not sync databases with these "Sql Server" facilities.
I am trying find out sync alternatives for that scenario without changing the hosting system.
What options can we use ?
Is Microsoft Sync Framework can be used for this scenario? ( I'm not sure if it is just for the Microsoft Azure Sql system)
Thanks…
if you're fine coding, then Sync Framework can do this.
Sync Framework can sync SQL Compact, Express, Server, Azure or LocalDB
But bear in mind that Sync Framework will need to create some Sync-related objects on your databases (triggers, stored procedures, tables, etc...)
It sounds like you need a hosting provider that provides these services.
It is typical for a hosting provider to provide an on-demand or always VPN connection to the production servers from the client location to the servers at the hosting location. Such a service is often needed for support of online systems. If you had such a connection then having SQL Server do syncs would be no problem.
Any major (Rack Space, Peer1, etc) provider would be able to set up such a system.
It probably won't be as inexpensive as your current provider.
Well if changing a provider is not an option, at list in the short term and you need something right now, you can always automate parts or all your current process.
For that you can at least use:
PowerShell (or even plain old cmd.exe) script(batch) and bcp.exe to export and import your files on both ends and PowerShell and ftp to transfer your files from one server to another.
SQLServer Integration Services on premises to export and send files via ftp to your hosting location. And SSIS to grab and import those files at your hosting location.
I'm trying to get data from another database using the OPENDATASOURCE command, but I get an error about DisallowAdHocAccess.
The SQL Server version is 2008 Express Edition, running on a remote site.
OPENROWSET can be used to access remote data from OLE DB data sources
only if the DisallowAdhocAccess registry option is explicitly set to
0. When this option is not set, the default behavior does not allow ad
hoc access.
HOW TO: Use the DisallowAdHocAccess Setting to Control Access to Linked Servers
Accessing External Data
An ad hoc name is used for infrequent queries against OLE DB data
sources that are not defined as linked servers. In SQL Server, the
OPENROWSET and OPENDATASOURCE functions provide connection information
for accessing data from OLE DB data sources. By default, ad hoc
names are not supported. The DisallowAdhocAccess provider option must
be set to 0 and the Ad Hoc Distributed Queries advanced configuration
option must be enabled.
Security Note
Enabling the use of ad hoc names means that any authenticated login to
SQL Server can access the provider. SQL Server administrators should
enable this feature only for highly trusted providers that are safe to
be accessed by any local login.
OPENROWSET and OPENDATASOURCE should be used only to reference OLE DB
data sources that are accessed infrequently. For any data sources that
will be accessed more than several times, define a linked server.
Neither OPENDATASOURCE nor OPENROWSET provide all the functionality of
linked server definitions. This includes security management and the
ability to query catalog information. Every time that these functions
are called, all connection information, including passwords, must be
provided.