I'm working on an application and am trying to offer the ability to use a "Local" database or a SQL Server database. What I'm trying to work out is the best Local DB format to use and how to write the queries.
At the moment i have been playing with SQL Server CE and it seems to work fine, but I then need to write each code block twice for any queries (once for SQL and once for SQL Server CE). Is there any solutions to this? Is there some way i can just pass a different connection string?
What i have at the moment is a "sub" that i have a check if using local (my.setting.uselocal) and then call either function Query_SQL or Query SQL. I imagine it will get tiring soon to have to have two blocks for each database query?
Any suggestions on how to do this more efficiently?
Cheers
You could try creating a .sdf file. These can be created programmatically, along with a databse(s)/tables etc in the file.
It's been a long time since I've used them but IIRC you can write read/write with the same tsql syntax. I would have thought it would allow you the same query functions and you can then pass in whatever connection.
I am having to develop an application very rapidly. I have chosen SQL Server (2012) as the DB backend, and I will write all my stored procs, triggers etc in the backend.
However, for UI (logon, reporting etc), I am using Access 2010 for the frontend. I am new to both Access used earlier versions of Access waaay back in the day) and SQL Server (familiar with other Db's).
The goal is to have the database reside on a server and let clients connect with an instance of Access 2010 running locally on their machine.
I am looking for a quick tutorial that shows me how to use the SQL server objects from the Access frontend (I believe its called linking) - any link to useful resource would be very helpful, as I can't seem to locate anything useful (I may searching using the wrong keywords).
Assuming you built all the tables and data on SQL server, then in Access it is a simple matter to link Access to that database.
And to save development time, you can continue to use the Access simple approach of using forms bound to those tables. As long as you launch a form with some kind of criteria (say an invoice number), then that bound form will ONLY pull down the one record from SQL server into that form. (so need to write or use store procedures etc. for that form). And any triggers etc. you have built in SQL server will run without you having to do anything from the Access side.
So a plane jane form build in Access that is bound to a table of say 1 million rows in Access does not need any “special” code – just make sure you launch the form with the “where” clause that Access provides and the form will only pull + load the one record.
So 99% of the normal development process you used in Access in the past will continue to work. Using SQL server for the most part does not change much if anything in regards to building forms that edit such data.
However, for reports and some forms that query + search for data etc., or some VBA code that needs to “process” data, you are most free to call store procedures. You simply create a pass-through query in Access. The VBA code to use that T-SQL thus looks like this:
Currentdb.QueryDefs("MyRawt-sqlPassThoughquery").Execute
Or
with CurrentDb.QueryDefs("MyPass")
.SQL = "exec sp_myProc"
.Execute
end with
In the past for most access applications you likely used liked tables – those linked tables can be to a Access file (back end), or Oracle, or SQL server – how the actual application works and functions is really much the same for all cases. (so there not really a lot of “specific” things you need to know from the Access side – if you comfortable with Oracle, or SQL server, then using Access as a front end works just fine, and the typical development approaches used in Access will remain typical.
Here is an article that outlines the linking process:
https://support.office.com/en-us/article/Import-or-link-to-SQL-Server-data-A5A3B4EB-57B9-45A0-B732-77BC6089B84E?ui=en-US&rs=en-US&ad=US&fromAR=1
Keep in mind you will see MANY articles that talk about ADP projects - they have been deprecated since Access 2010, and I don't recommend using ADP projects with Access - so be careful, since many articles that talk about Access + SQL server are built around ADP projects which as noted should not be used anymore.
This office.microsoft.com article should give you a good overview.
With plenty of more technical information searching for "query sql server from ms access".
Don't mess about with linked tables. Use an Access ADP (Access data project), which is natively connected to SQL Server. Sadly this type of access file is being phased out but it is the optimal solution for an MS Access front end with a SQL Server back end
Pros and Cons of Access Data Project (MS Access front end with SQL Server Backend)
I have a project to create a program that can operate in two modes:
internal users access a centralized database (SQL Server) and can view/edit each others items, or
external customers create all their own data locally (SQL Server Compact) and package it up in XML over e-mail to request a quote.
The question is, what's the best way to do this to minimize maintenance and maximize EF functionality? I'd also like to use stored procedures in SQL Server for write operations, but this isn't a top priority if too much trouble.
I could hand-create a separate SSDL before deployment, but this is extra work and error-prone. I could go Model First, but I think it would complicate database updates for both providers. I could go the Code First direction using the DbContext Generator T4 templates, but then I lose a lot of EF benefits like change tracking and stored procedure mapping. And with CF, I'd have to greatly enhance the T4 templates or I still have to create a separate SSDL.
Is there an article or any tools to make this easier?
Edit: I decided the best way to accomplish this was to use Code First to create my model and use the new code first migrations. With migrations I can generate a change script for the full server instance and I can just apply the full changes on the local CE database. The other advantage is that I have full control over my connection string and can really point it at any provider.
It's a little extra work to create the POCO classes by hand, to create the configuration classes (I prefer defining by Fluent API), and to add the extras (like unique indexes) to the first migration class, but in the end its the least work overall.
I'll have to figure out how to shunt in the stored procedures usage at a later date, but EF 5 might be available by then and have solved my problem.
I'd also like to use stored procedures in SQL Server for write
operations, but this isn't a top priority if too much trouble.
SQL Compact doesn't support stored procedures so if you mean this seriously you will not be able to reuse your mapping any way.
I could go the Code First direction using the DbContext Generator T4 templates, but then I lose a lot of EF benefits like change tracking and stored procedure mapping.
You will lose just stored procedure mapping . Change tracking will work in the same way. You will also be able to use same mapping code for both database server but you will have to figh with some minor differences between SQL server and SQL Server compact.
I could hand-create a separate SSDL before deployment, but this is extra work and error-prone.
You will have to do that if you want to use EDMX and both big SQL Server and SQL Server Compact with the same code base. Moreover you will have to limit features of your big SQL Server implementation to only features supported by SQL Server Compact.
I am totally new to SQL Server CLR. I understand that we should use CLR under the condition that business logic is really complicated to implement in SQL.
We have quite a few functions in VB.NET to process data, such as standardizing data. I am trying to implement them through CLR. The functions access a remote server first to get some reference data, then process on the local server.
However no matter how I try, I got Error
System.NullReferenceException: Object reference not set to an instance of an object.
or it returns null from the remote server.
Can we access a remote server in the CLR routine? If yes, how?
You can access remote servers in the .Net CLR but you really shouldn't.
SQL server operates in a cooperative multitasking environment, i.e. threads are trusted to terminate and complete their processing (one way or another) in a timely manner. If you start doing things like calling remote methods (which are liable to long delays) you are likely going to end up starving SQL server worker threads which will ultimately end up with Bad Things happening.
Also see this question
Yes you can. You can use the normal SqlCommand & SqlConnection classes in the .NET framework to do so.=, if the remote servers are SQL Servers, which I assume it is.
If they are web servers, yes you can, use web services.
On a side note. Be very careful what you do in the CLR, because as attractive as CLR looks you only have about 512MB of memory under SQL 2005, and by adding some startup parameters you can push it out to 2Gb. Just be aware.
EDIT:
Based on your comments, I suggest using a linked server, and then re-creating the remote table locally and then joining to it on the local server.
You will have to make sure you re-create indexes and keys on the local box, and for speed -sake, do it after you inserted the records into the table, else building your indexes on an already populated table, will take a long time.
Bear in mind here, I am not an Access guru. I am proficient with SQL Server and .Net framework. Here is my situation:
A very large MS Access 2007 application was built for my company by a contractor.
The application has been split into two tiers BY ACCESS; there is a front end portion that holds all of the Ms Access forms, and then on the back end part, which are access tables, queries, etc., that is stored on a computer on the network.
Well, of course, there is a need to convert the data storage portion to SQL Server 2005 while keeping all of these GUI forms which were built in Ms Access. This is where I come in.
I have read a little, and have found that you can link the forms or maybe even the access tables to SQL Server tables, but I am still very unsure on what exactly can be done and how to do it.
Has anyone done this? Please comment on any capabilities, limitations, considerations about such an undertaking. Thanks!
Do not use the upsizing wizard from Access:
First, it won't work with SQL Server 2008.
Second, there is a much better tool for the job:
SSMA, the SQL Server Migration Assistant for Access which is provided for free by Microsoft.
It will do a lot for you:
move your data from Access to SQL Server
automatically link the tables back into Access
give you lots of information about potential issues due to differences in the two databases
keeps track of the changes so you can keep the two synchronised over time until your migration is complete.
I wrote a blog entry about it recently.
You have a couple of options, the upsizing wizard does a decent(ish) job of moving structure and data from access to Sql. You can then setup linked tables so your application 'should' work pretty much as it does now. Unfortunately the Sql dialect used by Access is different from Sql Server, so if there are any 'raw sql' statements in the code they may need to be changed.
As you've linked to tables though all the other features of Access, the QBE, forms and so on should work as expected. That's the simplest and probably best approach.
Another way of approaching the issue would be to migrate the data as above, and then rather than using linked tables, make use of ADO from within access. That approach is kind of famaliar if you're used to other languages/dev environments, but it's the wrong approach. Access comes with loads of built in stuff that makes working with data really easy, if you go back to use ADO/Sql you then lose many of those benefits.
I suggest start on a small part of the application - non essential data, and migrate a few tables and see how it goes. Of course you back everything up first.
Good luck
Others have suggested upsizing the Jet back end to SQL Server and linking via ODBC. In an ideal world, the app will work beautifully without needing to change anything.
In the real world, you'll find that some of your front-end objects that were engineered to be efficient and fast with a Jet back end don't actually work very well with a server database. Sometimes Jet guesses wrong and sends something really inefficient to the server. This is particular the case with mass updates of records -- in order not to hog server resources (a good thing), Jet will send a single UPDATE statement for each record (which is a bad thing for your app, since it's much, much slower than a single UPDATE statement).
What you have to do is evaluate everything in your app after you've upsized it and where there are performance problems, move some of the logic to the server. This means you may create a few server-side views, or you may use passthrough queries (to hand off the whole SQL statement to SQL Server and not letting Jet worry about it), or you may need to create stored procedures on the server (especially for update operations).
But in general, it's actually quite safe to assume that most of it will work fine without change. It likely won't be as fast as the old Access/Jet app, but that's where you can use SQL Profiler to figure out what the holdup is and re-architect things to be more efficient with the SQL Server back end.
If the Access app was already efficiently designed (e.g., forms are never bound to full tables, but instead to recordsources with restrictive WHERE clauses returning only 1 or a few records), then it will likely work pretty well. On the other hand, if it uses a lot of the bad practices seen in the Access sample databases and templates, you could run into huge problems.
It's my opinion that every Access/Jet app should be designed from the beginning with the idea that someday it will be upsized to use a server back end. This means that the Access/Jet app will actually be quite efficient and speedy, but also that when you do upsize, it will cause a minimum of pain.
This is your lowest-cost option. You're going to want to set up an ODBC connection for your Access clients pointing to your SQL Server. You can then use the (I think) "Import" option to "link" a table to the SQL Server via the ODBC source. Migrate your data from the Access tables to SQL Server, and you have your data on SQL Server in a form you can manage and back up. Important, queries can then be written on SQL Server as views and presented to the Access db as linked tables as well.
Linked Access tables work fine but I've only used them with ODBC and other databases (Firebird, MySQL, Sqlite3). Information on primary or foreign keys wasn't passing through. There were also problems with datatype interpretation: a date in MySQL is not the same thing as in Access VBA. I guess these problems aren't nearly as bad when using SQL Server.
Important Point: If you link the tables in Access to SQL Server, then EVERY table must have a Primary Key defined (Contractor? Access? Experience says that probably some tables don't have PKs). If a PK is not defined, then the Access forms will not be able to update and insert rows, rendering the tables effectively read-only.
Take a look at this Access to SQL Server migration tool. It might be one of the few, if not the ONLY, true peer-to-peer or server-to-server migration tools running as a pure Web Application. It uses mostly ASP 3.0, XML, the File System Object, the Data Dictionary Object, ADO, ADO Extensions (ADOX), the Dictionary Scripting Objects and a few other neat Microsoft techniques and technologies. If you have the Source Access Table on one server and the destination SQL Server on another server or even the same server and you want to run this as a Web Internet solution this is the product for you. This example discusses the VPASP Shopping Cart, but it will work for ANY version of Access and for ANY version of SQL Server from SQL 2000 to SQL 2008.
I am finishing up development for a generic Database Upgrade Conversion process involving the automated conversion of Access Table, View and Index Structures in a VPASP Shopping or any other Access System to their SQL Server 2005/2008 equivalents. It runs right from your server without the need for any outside assistance from external staff or consultants.
After creating a clone of your Access tables, indexes and views in SQL Server this data migration routine will selectively migrate all the data from your Access tables into your new SQL Server 2005/2008 tables without having to give out either your actual Access Database or the Table Contents or your passwords to anyone.
Here is the Reverse Engineering part of the process running against a system with almost 200 tables and almost 300 indexes and Views which is being done as a system acceptance test. Still a work in progress, but the core pieces are in place.
http://www.21stcenturyecommerce.com/SQLDDL/ViewDBTables.asp
I do the automated reverse engineering of the Access Table DDLs (Data Definition Language) and convert them into SQL equivalent DDL Statements, because table structures and even extra tables might be slightly different for every VPASP customer and for every version of VP-ASP out there.
I am finishing the actual data conversion routine which would migrate the data from Access to SQL Server after these new SQL Tables have been created including any views or indexes. It is written entirely in ASP, with VB Scripting, the File System Object (FSO), the Dictionary Object, XML, DHTML, JavaScript right now and runs pretty quickly as you will see against a SQL Server 2008 Database just for the sake of an example.
It takes perhaps 15-20 seconds to reverse engineer almost 500 different database objects. There might be a total of over 2,000 columns involved in this example for the 170 tables and 270 indexes involved.
I have even come up with a way for you to run both VPASP systems in parallel using 2 different database connection files on the same server just to be sure that orders entered on the Access System and the SQL Server system produce the same results before actual cutover to production.
John (a/k/a The SQL Dude)
sales#designersyles.biz
(This is a VP-ASP Demo Site)
Here is a technique I've heard one developer speak on. This is if you really want something like a Client-Server application.
Create .mdb/.mde frontend files distributed to each user (You'll see why).
For every table they need to perform an CRUD, have a local copy in the file in #1.
The forms stay linked to the local tables.
Write VBA code to handle the CRUD from the local tables to the SQL Server database.
Reports can be based off of temp tables created from the SQL Server (Won't be able to create temp tables in mde file I don't think).
Once you decide how you want to do this with a single form, it is not too difficult to apply the same technique to the rest. The nice thing about working with the form on a local table is you can keep a lot of the existing functionality as the existing application (Which is why they used and continue to use Access I hope). You just need to address getting data back and forth to the SQL Server.
You can continue to have linked tables, and then gradually phase them out with this technique as time and performance needs dictate.
Since each user has their own local file, they can work on their local copy of the data. Only the minimum required to do their task should ever be copied locally. Example: if they are updating a single record, the table would only have that record. When a user adds a new record, you would notice that the ID field for the record is Null, so an insert statement is needed.
I guess the local table acts like a dataset in .NET? I'm sure in some way this is an imperfect analogy.