I am trying to write unit/integration test cases for a Java codebase connecting to MS SQL Server. In this effort, am able to successfully copy all my SQL Server tables over to a H2 Database file and run my unit tests on the H2 DB.
I have thoroughly reviewed the H2 DB Compatibility features.
On my JDBC URL, I have the mode set -
jdbc:h2:~/test;MODE=MSSQLServer
Attempted connecting to the H2DB file and executed
SET MODE MSSQLServer
I attempted this on both in-memory and file mode and both are not working in compatibility mode.
Both these do not seem to work. My application SQLs contain NOLOCK hints and identifiers with square brackets. Both these are quoted to be supported in the compatibility documentation. I even reviewed the H2DB's github for their MS SQL Server unit test and found these to be supported.
Still wondering anything that I may be missing.
Finally figured out that I was using an old version 'h2-1.4.197' where MS SQL Server compatibility is not enabled.
So upgraded to version 'h2-1.4.200' where hints like (NOLOCK) are being ignored once we are on SQL Server mode. Square brackets are still not being ignored - but guess atleast the compatibility mode is working. So will leave it at this.
Related
Since yesterday I have connections to two different SQL Servers in Visual Studio Code (VSCode). One is a SQL Server (called "DS") and the other is to our development environment which is SQL Server Express (called "AS"). Now VSCode seems to have locked on DBDS08 and I don't know how to change it so I'll run my SQL queries against AS. I don't the servers are linked.
Does anyone know how I should do to change between these SQL connections in VSCode?
The VSCode version I'm using is 1.59.0.
The SQL packages installed is:
SQL Server (mssql), version 1.13.0
SQL Database Projects, version 0.14.1
Due to security reasons VSCode is run from an environment that is without internet connection.
#Larnu is correct. On the bottom right, select the server path. A few seconds later the command panel extends with actions to take. Select disconnect. You will see a confirmation in the same place, select yes. To connect to another server select the Text Disconnected on the bottom right and in the command are select the server you want to connect to.
I have this issue which I have asked about here
In all my programmatic attempts to fix the issue above, things like this are displayed in the messages box:
Reference to database and/or server name in
'master..sp_addsrvrolemember' is not supported in this version of SQL
Server.
How do I find the version of SQL Server,I am using? It seems nothing is supported by my version.
Is the issue can be that - I am not using SQL Server somehow? I am using Microsoft Azure to host my database. Does that make you use SQL Azure? In SSMS, in the Object Explorer, at the top where it says the server, it says gonskh1ou0.database.windows.net(SQL Server 13.0.201 - Amber). Amber is my user name, and is the administrator. SQL Server 13.0.201 is not in this list of SQL Server build numbers
Yes, you are using the Azure version of SQL Server, which does not support sp_addsrvrolemember.
(Do note that that stored procedure is deprecated and you should be using ALTER SERVER ROLE, which is supported at least in Azure SQL Data Warehouse's preview.)
The only way to run a full SQL Server is to create a VM and run it there yourself. The Azure version will never be the full version.
You are using Microsofts implementation of SQL server, the version number and name(Amber) supplied are indeed correct. Depending on the level of Azure account you are using, this server is usually configurable.
Microsoft Azures platform contains some very nice support and I would advise consulting directly with a rep. They have always been very helpful and quick to help in regards to configuration issues, even performing the configurations for you if required.
I recently changed my compatibility mode of my sql server 2005 form 2000 to 2005.
Is there a utility that can scan my sp and functions and tell me if I have any compatibility issues?
I am not sure if it works from inside sql 2005; but if you still have a sql 2000 server then MS have an upgrade advisor that will report on your code. If you don't scripting out all the objects and trying to run them back into a new database set as sql 2005 mode is a fairly good way to test the migration.
Depending on your application be careful just switching there are syntax differences and connection options that changed between 2000/5 beyond just stored procedure changes. If your application runs sql queries natively (not sp's) then the application may have compatibility issues beyond just the internal database code.
I am releasing a database build to SQL Server 2000 via a batch file using isql. The batch file is used so multiple files are released consistently to different SQL Servers (development, test, live).
The SQL Server uses ANSI code page 1252 (from sp_helpsort) but isql is an OEM client using code page 437. This means that all extended characters (with ASCII code > 128) are converted when the scripts are run, leading to inconsistent results when characters like “£” are included in the script. Differences are explained in this Microsoft knowledgebase article.
Possible solutions are: -
Save the script using Unicode and
use osql.
Turn off the AutoAnsiToOem setting using the SQL Server Client Network Utility (that writes a registry key).
Both these options rely on various people doing things consistently. All have to select the same code page option when saving a file OR all people performing the builds have to have the same option set for AutoAnsiToOem.
Is there a way to force the use of a code page either in the SQL script OR in the batch file that calls it, so that the build is always released consistently, regardless of how the file is saved or the various settings of whoever performs the release?
isql is obsolete. It isn't included in SQL Server 2005 or later, because it uses the DB-Library connections, which are also obsolete. For the reasons why, and the effects this has, see Connecting Early Version Clients to SQL Server 2000.
osql uses ODBC connections to connect to SQL Server. For completeness, this has been supplemented by sqlcmd in SQL Server 2005, which uses OLE DB with the SQL Native Client provider.
Further to the accepted answer, I have tested using sqlcmd against a SQL Server 2000 database and it works. You obviously have to run sqlcmd from a machine with the SQL Server 2005 client tools installed.
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.