I need to replicate my DB without adding it any columns (like the MS SQL replication does), I looked every where and every project I found was last updated 2-3 years ago (in the best case i found a project last version was from 2011).
The replicator needs to support MS SQL 2005 (2008 is not required now) over JDBC driver and it's also preferred that the project is still active and updated (bug fixing, features requests, support etc.)
if any one knows any replicator with these characteristics please help me !
just to be clear, the DB replicated is a MS SQL created by ActiveMQ 5.5.1 using Microsoft JDBC driver 3.0
Related
I have a project where the choice of database engine is still up in the air, based on affordability and feature-set. Some basic groundwork has been carried out using SQL Server, and in evaluating the cost implications of opting to adopt SQL Server, versus a different vendor's product, I noticed that Microsoft has just released their public preview of SQL Server v.Next, which allows one to run SQL Server on a Linux platform.
According to www.theregister.co.uk, the public preview is a SQL Server executable that runs on *nix-based systems by utilising Drawbridge, which is essentially a way of running Windows applications on a tiny version of the Windows 8 kernel, run inside a sandbox.
One issue most open source advocates have had with Microsoft's SQL Server is that SQL Server Enterprise contains all functionality, and when opting for a more budget-friendly version, certain limitations are imposed on you.
Specifically, Standard Edition and Web Edition impose upper limits on in-memory column store (32GB and 16GB respectively), and Web Edition removes backup compression as a feature.
I've searched the web in an attempt to find out how Microsoft intends to license SQL Server as far as Linux versions are concerned, my main concern being related to database mirroring. As far as database mirroring is concerned, SQL Server Standard and SQL Server Web Editions both have a subset of the functionality provided by SQL Server Enterprise.
I'm looking to understand three things:
How is Microsoft going to license SQL Server vNext for Linux (specifically, the Ubuntu version)?
If vNext is a subset of the functionality of the Windows version of SQL Server, what functionality is omitted?
Is database mirroring functionality present in the Linux distros of SQL Server vNext?
I don't think licensing information has been released yet.
What we do know is SQL Server Next on Windows & Linux will run a single feature set. Here is a quote taken from MS at Connect().
Microsoft officials said SQL Server Next on Linux and SQL Server Next
on Windows are based on a single code base. "There are some features
that have platform specific characteristics. For example, file paths
in Linux are different than file paths in Windows," said a
spokesperson. But they are not two completely different products.
My take on this is: SQL Server 2018 (or whatever it ends up being called) will be the same on Linux and Windows. This lines up with the big news about SQL Server 2016 Service Pack 1. MS have announced all editions will be functionally the same, from LocalDb to Enterprise.
While the Linux version remains in preview it is hard be sure what the final product will look like. If this is choice you have to make soon you may well feel the Linux solution isn't, quite, ready for prime-time.
I'm currently evaluating options for synchronizing two identical databases that will be deployed on two different SQL Server (1) instances. I've started with the Microsoft Sync Framework and if it does not fit my requirements I'll check SQL Replication.
Anyway, long story short, I'm trying to get a basic scenario to work using the Sync Framework but unfortunately all of the examples and tutorials I've seen online use the SQL Provisioning Provider which adds certain tables, stored procedures and triggers to the database - I want to avoid this, obviously.
I read somewhere that the Sync Framework can use SQL Server's built-in Change Tracking features, but this only works when the client is SQL CE (example). But all what I have read so far seems to be out-dated. I couldn't find anything that is relatively recent about the topic. So I was wondering whether the above is still valid or the Sync Framework added support for the built-in Change Tracking with SQL Server 2012 (or 2014).
In case this scenario is still not supported until this day, could someone refer me to an example (or at least some hints) of how I could develop a custom provider to use Change Tracking on both the client and the server?
(1) SQL Edition is not a constraint. Even SQL Server Enterprise Edition is an option.
support for SQL Change Tracking only works for the older SqlCeClientSyncProvider/DBSyncProvider/SyncAgent, in short you can only use to sync SQL Ce with a SQL Server configured for SQL CT.
the newer sync providers do not support SQL CT.
there used to be a sample SQLExpressClientSyncProvider from MS that has been pulled out from the download site due as it has some issues.
Writing a custom sync provider is not easy, if you can go for SQL Replication, that will be an easier route.
I'm trying to determine whether DNN 2.0.4 will be compatible with SQL Server 2005 SP4. My company is upgrading their server framework and they're trying to determine (without testing obviously...) if the SQL upgrade will blow up some of their older DNN sites.
I've trolled the boards, liberally dusted with Google magic and even skimmed through the super user manual. The nearest I've been able to get to an answer is that the latest version REQUIRES SQL Server 2005 but there's no indication that it will work with the older DNN.
Anybody out there have any concrete experience I can fall back on?
Because of the large installed base and wide variety of environments, the DNN core team has focused on using very standard SQL and I think if there was any problem, your searching would have turned something up.
Also, I'm not aware of any breaking changes or features in SQL Server 2000 that were removed in SQL Server 2005.
You should be fine. If you do run into a problem it's much more likely to be with a 3rd party module rather than the core. Some 3rd party modules were much quicker to begin to use the new capabilities of SQL Server 2005 and in general are less likely to follow standards or be tested as extensively in a wide variety of environments.
I am running 2.1.2 on SQL Server 2005 without issues. I think that the same would be true of 2.0.4.
We have a simple console app that uses EF 4 to process data; read from one, do some stuff, insert into another database. In the EDMX file, ProviderManifestToken for the destination db is set to "2005".
Yesterday, our app blew up. To make a long story short, our consultant says the db, which should be SQL Server 2000, was upgraded to 2005. That upgrade, according to them, was the reason for the app implosion. No one can explain how the upgrade occurred.
Can the value of ProviderManifestToken cause an upgrade to the db? For example, if a db is currently 2000 and this app runs with "ProviderManifestToken = 2005", can that force an upgrade on the db? What happens, if anything at all, if the versions do not match?
Do you think that Entity framework contains installation DVD to upgrade your SQL Server 2000 to SQL Server 2005? No it doesn't. Provider manifest token only describes dialect (EF generates queries based on the dialect). It doesn't trigger any changes on the database. Somebody had to upgrade your database (upgrade to a new version is not free - you must have licence for that, it is not something downloaded through windows update).
Btw. SQL Server 2000 is not supported by EFv4 anyway. If you had your dialect set to 2005 and your solution worked with your database then it was 2005 all the time because linq-to-entities queries using First, Single, Take, Skip, etc. generated for 2005 dialect don't work on SQL Server 2000.
Yes, I know. The existence of a running copy of SQL Server 6.5 in 2008 is absurd.
That stipulated, what is the best way to migrate from 6.5 to 2005? Is there any direct path? Most of the documentation I've found deals with upgrading 6.5 to 7.
Should I forget about the native SQL Server upgrade utilities, script out all of the objects and data, and try to recreate from scratch?
I was going to attempt the upgrade this weekend, but server issues pushed it back till next. So, any ideas would be welcomed during the course of the week.
Update. This is how I ended up doing it:
Back up the database in question and Master on 6.5.
Execute SQL Server 2000's instcat.sql against 6.5's Master. This allows SQL Server 2000's OLEDB provider to connect to 6.5.
Use SQL Server 2000's standalone "Import and Export Data" to create a DTS package, using OLEDB to connect to 6.5. This successfully copied all 6.5's tables to a new 2005 database (also using OLEDB).
Use 6.5's Enterprise Manager to script out all of the database's indexes and triggers to a .sql file.
Execute that .sql file against the new copy of the database, in 2005's Management Studio.
Use 6.5's Enterprise Manager to script out all of the stored procedures.
Execute that .sql file against the 2005 database. Several dozen sprocs had issues making them incompatible with 2005. Mainly non-ANSI joins and quoted identifier issues.
Corrected all of those issues and re-executed the .sql file.
Recreated the 6.5's logins in 2005 and gave them appropriate permissions.
There was a bit of rinse/repeat when correcting the stored procedures (there were hundreds of them to correct), but the upgrade went great otherwise.
Being able to use Management Studio instead of Query Analyzer and Enterprise Manager 6.5 is such an amazing difference. A few report queries that took 20-30 seconds on the 6.5 database are now running in 1-2 seconds, without any modification, new indexes, or anything. I didn't expect that kind of immediate improvement.
Hey, I'm still stuck in that camp too. The third party application we have to support is FINALLY going to 2K5, so we're almost out of the wood. But I feel your pain 8^D
That said, from everything I heard from our DBA, the key is to convert the database to 8.0 format first, and then go to 2005. I believe they used the built in migration/upgrade tools for this. There are some big steps between 6.5 and 8.0 that are better solved there than going from 6.5 to 2005 directly.
Your BIGGEST pain, if you didn't know already, is that DTS is gone in favor of SSIS. There is a shell type module that will run your existing DTS packages, but you're going to want to manually recreate them all in SSIS. Ease of this will depend on the complexity of the packages themselves, but I've done a few at work so far and they've been pretty smooth.
You can upgrade 6.5 to SQL Server 2000. You may have an easier time getting a hold of SQL Server or the 2000 version of the MSDE. Microsoft has a page on going from 6.5 to 2000. Once you have the database in 2000 format, SQL Server 2005 will have no trouble upgrading it to the 2005 format.
If you don't have SQL Server 2000, you can download the MSDE 2000 version directly from Microsoft.
I am by no means authoritative, but I believe the only supported path is from 6.5 to 7. Certainly that would be the most sane route, then I believe you can migrate from 7 directly to 2005 pretty painlessly.
As for scripting out all the objects - I would advise against it as you will inevitably miss something (unless your database is truly trivial).
If you can find a professional or some other super-enterprise version of Visual Studio 6.0 - it came with a copy of MSDE (Basically the predecessor to SQL Express). I believe MSDE 2000 is still available as a free download from Microsoft, but I don't know if you can migrate directly from 6.5 to 2000.
I think in concept, you won't likely face any danger. Years of practice however tell me that you will always miss some object, permission, or other database item that won't manifest itself immediately. If you can script out the entire dump, the better. As you will be less likely to miss something - and if you do miss something, it can be easily added to the script and fixed. I would avoid any manual steps (other than hitting the enter key once) like the plague.