I have a website developed using a SQL Server database. But I need to port it to a new web server that doesn't have access to a database.
I therefore need an alternative solution, preferably without rewriting all the database queries. I would prefer being able to run the same queries against a sqlite file or just a plain textfile.
As far as storage goes it won't be storing large amounts of data, so performance won't be an issue.
Thanks for your time!,
Kind regards
Solved it by using Sql Server Compact Edition (see comments in OP).
Related
We have a 3gb file of data from our propriartary CRM system which is using SQL as a database.
The CRM is not meeting our needs and we are thinking about moving to Microsoft access and building our own system from the start.
We were wondering if it is possible to easily migrate the SQL database into access?
Thanks for your time.
First of all, it has been a long time since I've had to use MS-Access (thankfully) but I'm not sure Access is suitable for databases of that size. In my opinion, it's best suited to small, desktop-type applications with few concurrent users.
To answer your question, I believe Access offers a data import feature(see under the External Data ribbon in 2013) - though I'd suspect it might balk at the idea of 3GB of data. Edit: Actually this link suggests the max databsae size is 2GB
What might be more useful however, is its Linked Table feature. If I remember correctly this allows you to access data stored in SQL Server (or a similar RDBMS) which is more suited to large volumes of data through an Access front end - complete with pre-canned forms, queries, reports etc..
It is possible and fairly straight forward to move all of your data tables from SQL Server to Access; however, SQL Server is a much more robust database engine than Access. I would highly recommend against that. I have however had very good success using Access (ADP project files) as a front for the interface and using SQL Server as the database back-end for simple to moderate complexity interfaces. If you are not getting the performance you desire from your SQL Server, you might want to consider query performance tuning and looking into memory and hardware upgrades first. I think you will get better and faster results from doing that.
The simple solution would be to “link” Access to SQL server. That way you continue to use a robust data engine, but are free to use all the reporting and coding features of Access.
In this setup then Access simply becomes a “front end” to the existing SQL database.
And you do NOT want to use an ADP project in Access since they are depreciated.
The process is thus to create a blank standard database, and then use linked tables to SQL server. This will not only eliminate the need to import data (which is likely changing all the time).
I am looking to import entries to my SOLR server by using the DIH, connecting to an external PostgreSQL server using the JDBC driver. I will be importing about 50,000 entries each time.
Is connecting to an external SQL server for my data unreliable or risky, or is it instead perfectly reasonable?
My only alternative is to export the SQL file on the other server, download the SQL file to my SOLR server, import it to my Solr servers copy of PostgreSQL and then run the DIH on the local database.
The way you're using it is pretty much why the DIH exists. Otherwise, you could just use the /update handler with XML documents. The core I'm working on right now regularly indexes 11,000,000 rows per batch.
This is a standard use case, importing from a remote DB. Proceed with confidence!
I want to setup replication between SQL Server and MySQL, in which SQL Server is the primary database server and MySQL is the slave server (on linux).
Is there a way to setup such scenario? Help me .
My answer might be coming too late, but still for future reference ...
You can use one of the heterogeneous replication solutions like SymmetricDS: http://www.symmetricds.org/. It can replicate data between any SQL database to any SQL database, altough the overhead is higher than using a native replication solution.
of course you can replicate MSSQL database to MYSQL
By using Linked Server in MSSQL.
for that you need to download ODBC drivers. and you can further search regarding how to create Linked server on SQL SERVER.
This option is very easy and Totally free. You can use OPEN QUERY FOR THIS.
By using SSIS Packages.
for that you need the Business Intelligence service of SQL SERVER. you can create SSIS Packages on Visual Studio and run them for replication.
No. At least not without doing a lot of dirty, bad things. MSSQL and MySQL speak different replication protocols, so you won't be able to set it up natively (which is the way you'd want to handle it). At best, you could hack together some sort of proxy that forwards insert/update/delete/create/alter, etc. queries from one to the other. This is a terrible idea as they don't speak the same SQL except in the most common case. Even database dumps which wouldn't really be replication are generally incompatible between vendors.
Don't do it. If you must use different OSes on your servers, standardize the database to something that runs on both.
These two databases are from two different vendors. While I cannot say for sure, it is unlikely Microsoft has any interest in allowing replication to a different vendor's database server.
I work with Informix and MySQL. Both those databases have commands that dump the entire database to an ascii file format. You would need to see how that is done on MS SQL Server; ftp the dump to the server hosting the MySQL server; and then convert the dump into something MySQL can import.
I'm using SQLite ADO.NET in my project so that I can unit test using an in-memory database. I want a copy of my real database but it is across the server. From what I've read, it looks like I have to specify ":memory" for the data source for the SQLite connection string. My problem is that I don't even know if it's possible to load a remote database into memory that is not a SQLite database, or how to do it? Any thoughts on how this could be done? It's not a large db--maybe 5 megs at most. Thanks for the input!
Actually, figured out it doesn't matter--I can't use SQLite with ADO.NET because my queries are all T-SQL.
You don't really need an in-memory database, you can use SQL Server Express on your PC, or a unit-testing VM.
You could overwrite the database file each time you run the test.
I've recently been upgraded to Office 2007. I have several Access databases (that I've kept in the Access 2000 format for several reasons) that are linked to SQL Server 2000 databases. I have dozens of queries in these databases that I use often. I create new queries daily, sorting, summarizing and generally analyzing the data.
Since the upgrade, some queries take an extremely long time to complete (minutes rather than seconds), and one new one I've tried to run doesn't complete at all, I have to end task on Access. It's a rather simple query, it joins 3 tables, and sorts on one of the fields. I do this ALL THE TIME, and now it appears I can't.
I've searched for discussions of similar problems, but haven't seen specific recommendations.
Any ideas?
I would suggest deleting all your ODBC linked tables and recreating them from scratch as a starting point.
If your queries do not need to make any changes to the data you may find converting them to SQL Pass through queries will speed them up considerable. Note these queries are not parsed through the Jet DB Engine but sent directly to the server and bypass any linked tables.
You will have to use MS SQL syntax and lose the QBE grid though and the result will be read only.
If you need to update data then maybe stored procedures are the way to go.
When I converted to SQL Server backend, I used SQL Server Migration Assistant. I recommend it highly. It's very good at what it does.
Having said that, I assume you're using linked tables in your FE. I convert slow-moving queries by copying the SQL from Access, then pasting it into a "new query" window on SQL Server Management Studio. Then, working through all the syntax changes one at a time, I convert the query to T-SQL and save it as a view with the same name as the query in Access.
I have a little routine that then renames the Access query to "Local_" and then creates a linked table entry to the view on SQL Server. You'll find that a query that used to run for minutes will run for seconds this way. You can, of course, do this manually.
SQL Server Migration Assistant, by the way, will convert many queries (it doesn't try to convert action queries, only select queries...) with little or no intervention.
I would use Access Data Projects with SQL Server 2000. It works great when your SQL backend is that old.