I have a need to make a remote connection through a DSL line (getting about 16k/s) to a SQL Express 2005 instance much faster.
I think I can do it by having a SQL Express 2005 instance on the client's local machine and have it be a cached version of the data on the server.
I'm planning to allow changes to the remote server only and then require the user pull down updates from it occasionally. It's not ideal, but it'll work.
So, does SQL Express support me querying across the network something like:
INSERT INTO local.dbo.users (id, username, email, timestamp_modified)
SELECT remote.dbo.users(id, username, email, timestamp_modified)
WHERE remote.dbo.users.timestamp_modified > LAST MODIFIED
For one you can use real Replication. You should also look into Service Broker. Both allow you to push the data from remote to a SQL Express instance. Service Broker performs and scales much better, is proven to work over slow DSL connections, but has a steep learning curve. Replicaiton is easy to set up but you'll have to live with it's limitations.
Using linked servers like you plan is not going to work. Is unreliable, slow, and doing updates over a linked server requires you to set up distributed transaction.
Why write something that has already been built and is available to you with the product you already have installed?
You should look into Log Shipping over your DSL line. It is a very reliable SQL Server product and has been tested extensively.
http://msdn.microsoft.com/en-us/library/ms187103.aspx
Although the express edition does not have SQL Server Agent, there are workarounds that you can use:
http://blog.willbeattie.net/2009/07/log-shipping-in-sql-server-express-2008.html
Related
I have an application that cannot be modified that connects to a SQL Server database using a hardcoded connection string with windows authentication.
I need to move the database to another server but as I cannot modify the hardcoded connection string - I am looking for something to act as a local connection that will then relay the query to the remote database and return the result back to the app.
The only other way I can see to do this is to upgrade from SQL Server Express and use database replication but that will be expensive option for what I need.
Can anyone suggest any software to do this or recommend an alternative method?
Thanks
Update:
The connection string also uses Windows authentication which will not work on the remote server.
If your workstations don't need access to the old server, you could perhaps solve this with DNS, using a cname record to point the old server name to the new. If you can't do this organization wide, you might be able to use entries in the hosts file on the impacted workstations.
I just saw this in the comments:
the database server is the same machine where the app runs (ie, 'localhost')
In that case, you want to figure out what the connection string is using, and the hosts entry should be able to accomplish this.
In old server you can define linked server, pointing it to new one and create queries to link to remote tables; you can use different credentials for it. You may get some performance problems (esp update statements may slow down).
Help needed here. I'm a bit lost checking all possible editions and configurations of SQL Server.
What I'd like seems straight forward: a version of SQL Server (ideally 2008, or higher), on a single PC (client+server), with a small footprint. I just want to self train in ddbb's basic administration (user creation, schemas, scripts, copying ddbbs, stored procedures).
These ddbb's won't be used with webs, other users, etc. Just myself, at most with an Access front-end linked to the SQL Server DB.
My doubts are:
Is is better SQL Server Express 2008, Compact Edition (CE), SQL
Lite, something else ??
I would prefer using SQL Lite (seems the
simplest), but my concern is how 'similar' (for things like schemas,
permissions, scripts management, files names, no worries about multiple servers, though) is SQL lite to
a full SQL Server ?
I'd just like to familiarize with the basics in my pc so that when confronted to a real SSIS I can learn it quickly.
Thanks in advance, p.
I'd go with SQL Express if you're planning to learn SQL Server. Although SQLite has a small footprint it is completely different from SQL Server. Queries to get and manipulate data are similar (but not identical in every manner), but everything related to metadata (schemas etc.) is completely different.
I have a client that uses a point-of-sale solution involving an Access database for its back-end storage. I am trying to provide this client with a service that involves, for SLA reasons, the need to copy parts of this Access database into tables in my own database server which runs SQL Server 2008. I need to do this on a periodic basis, probably about 5 times a day.
Is there an easy programmatic way to do this, or an available tool? I don't want to handcraft what I assume is a relatively common task.
I am running this on SQL Azure, so there's no way for me to run prepackaged software on the server. It would either have to be open source and portable to Azure or executable on the client's computer.
I'm unfortunately thinking I'm going to have to roll my own tool to do this. Any suggestions or more tools that are out there that can do this themselves before I go ahead?
David, I looked at multiple solution for a similar problem: converting from dbf to mysql, here are 3 solutions (all commercial - but relatively inexpensive) that can work for you:
Full Convert
SQL Manager
ESF
Other than that I couldn't find a good robust data conversion tool that would be open source or free. At least not for DBF to MySQL conversion. There might be something out there for SQL/Access. You could roll out your own solution, but is it worth your time?
DISCLOSURE: I ended up using Full Convert.
Also all of these products generate some sort of batch file, that can be scheduled using Task Manager.
There are two things to consider:
connectivity
ETL tool
For connectivity, you will need to establish VPN tunnel of some sort between the client server and your server.
Then use SSIS to connect to MS Access, to create packages to pull data from MS Access to SQL Server database. On SQL Server, you will need to create new schema, to mirror or be close MS Access
On connectivity side, another option - since MS Access db is in the file, you may be able to FTP the file to your server and point SSIS to the file
There are actually two related questions:
is it possible or advisable to use a full blown stand-alone SQL server for SharePoint Services WSS3.0 instead of the supplied windows internal database it comes with? The client I am working for is asking to utilize their existent SQL server for all WSS content databases to possibly minimize admin effort and improve performance.
As well, would you advise to install WSS on one physical server and the content database on another server? Any gain in performace? Practicality? ect. The default is WSS and all of its databases are installed on the same single server. We don't really need a farm setup of MOSS, because the WSS capabilities are enough for our needs.
Thanks,
Val
Yes, when you create the site check the installation to be a "Web Front End" It will then prompt you to select a location for the SQL database. Just point it to which server you want.
I would definitely recommend putting it on a non-Sql Express instance. The express version only scales to 4 gig, limits the maximum number of connections etc. If your client is going to do much with it at all, you will eventually hit that limit. Full blown sql server has other advantages too, like help with backups etc.
Yes and yes.
Keeping the SQL and WSS servers separate saves resources on both, and neither are light weight applications. It also allows you to easily begin clustered/distributed environment in the event your usage increases, as well as following a least privledge principle, keeping product patches separate, etc.
As an addendum, you say you don't need a MOSS farm because WSS fits your needs, but be aware that it's just as easy to setup a distributed WSS environment as is MOSS; MOSS only adds capabilities to the application. It's usually a good idea to have at least two WFE's in the farm, if for nothing else than redundancy in case of failure.
Yes you can use a 'full blown' SQL Server instead of the the free and limited SQL Server Express that is delivered with Windows SharePoint Services 3.0 (wss 3.0)
It's even better to separate the database and the actual website! More scalable (if you upgrade to MOSS), easier to manage and less security risks.
We upload sales transactions from our stores to the headoffice server. At the moment, we use DTS (SQL Server Data Transformation Services), but we’re planning on replacing that with Microsoft Sync services for ADO.NET, as this seems to be Microsoft’s preferred solution for this type of setup and we want to follow the standard (that will be hopefully be around for a long time).
Here are the details of our setup and what we’re planning. I’m looking for some advice, especially about whether Sync Services fits into our solution.
Situation
Each store has a 3rd party EPOS system which stores sales in a Microsoft Access 2000 database, which we can access. Our headoffice database is SQL Server 2005, but will be upgraded to 2008. The headoffice is not on a VPN with all the stores, but we can open up our firewall to the stores’ IP addresses, so that they can send data directly to SQL Server. The stores are always connected to the internet via ADSL, although they do lose connection and we don’t want to lose sales data.
We are only uploading transactions from the store – definitions do not need to be downloaded.
Current solution
We have written a Windows service that runs on the store PC. This service downloads a DTS package from the server (which contains all the details of the upload) and runs it in the store – and this will upload sales to our server.
We chose DTS, because it is free when you install MSDE. We can’t use SSIS, because that would require a SQL Server licence at every store.
Another reason we chose DTS is that the details of the upload (i.e. which tables and fields to include) are stored on our headoffice server, so if we need to change things we can do that centrally and don’t need to install anything new at the stores. This isn’t a showstopper, but would be nice to have this ability in our new solution.
Potential solution - Microsoft Sync services for ADO.NET
We are currently building a proof of concept with Microsoft Sync services for ADO.NET. The idea is to put SQL CE (SQL Server Compact 3.5) in each store (client) and sync that to the headoffice SQL Server 2005 database (server). We’ll get the data into the SQL CE database either by (1) syncing it with the Access 2000 database or (2) getting the EPOS system developers to write sales straight into the SQL CE database – probably (2). But our main concern is getting the data from the store to the headoffice server. This method seems to be Microsoft’s preferred solution for occasionally connected systems and that is what made us look seriously at Sync Services.
I’m hoping that using this will mean that most of the work needed to upload the sales will be built into Sync Services and we won’t have to re-invent the wheel.
Potential solution - Upload to a custom webservice
There is also the possibility of uploading the sales transactions to a custom web service on our headoffice server and then into our SQL Server database. This means that we will have to build our own mechanism for determining which rows are new, and as well as caching for when the systems are disconnected. Also, we might be missing out on other functionality that will come built into Sync Services.
Please let me know if you have any advice that will help, especially : “Is Sync services the right solution!”. The problem that we are trying to solve seems very generic (uploading sales from stores) – and I’d like to solve it with a generic solution.
Microsoft Sync services is more than you need, but it will certainly do what you want, and it was built with your type of application in mind.
As with most new technologies out of microsoft, (caution: generalization!) you may find that it's not as mature as you might like. It'll do what you need it to, but you may run into issues that aren't easily resolved because it hasn't been put through the ringer. As an early adopter, though, you may find that the Sync developers are eager to help you out when you get stuck, so this isn't as big a problem as it might seem.
Make sure you read through all the literature on it, some of which is here, or linked in the following sites:
http://msdn.microsoft.com/en-us/sync/default.aspx
http://msdn.microsoft.com/en-us/sync/bb887608.aspx
http://en.wikipedia.org/wiki/Microsoft_Sync_Framework
Given your one-way flow of information, though, and centralized layout I expect you should have few, if any, issues setting it up and using it.
Be sure to report your experience back here!
-Adam