When I use CFDBINFO on my local system, it accurately picks up default column values and returns them. On a different system, it does not (it doesn't seem to notice any default constraints).
Both systems are using CF 9,0,1,274733 and both are connecting to MSSQL Server 2008. The code on both systems, including the scripts that build the tables, are identical (same repo, same version #). (I also ran the test on a third system and got accurate results)
I've tested this issue with multiple different tables and it occurs every time: default values are never returned on the wayward server. I've made fresh tables, from scratch, totally new names, totally new database, still see the issue. I don't see any other differences in the introspection results- in fact FKs and other constraints appear fine.
Just have no idea how to debug this. Doesn't appear to be cache related. Systems are pretty identical. Is there some byzantine setting? Perhaps an issue with the sql connector? Or java version? Suggestions??? Thanks!
Adding notes based on suggestions below here for better formatting:
Looking at MSSQL Versions, I get:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Express Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Express Edition with Advanced Services (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor)
Pretty much the same, except that (Hypervisor) bit-- not sure that's worth pursuing.
answer: make sure the db user has ddl_admin permissions.
I would try the following:
Do a side by side compare of the cf_root/lib/neo-datasource.xml files on each server. They are probably different.
Check to see if the MSSQL servers have a slightly different version. You may be looking at a service pack issue
Addendum
3) On each of the DBs, use the "Generate Script" functionality to generate the scripts to build all the tables, views, defaults, etc. Compare what each of the resulting scripts have
For additional info on 1, see http://helpx.adobe.com/coldfusion/kb/purpose-location-xml-configuration-files.html
Related
I'm trying to attach a SQL Server .mdf to my Management Studio 2014, but I get the error:
Attach database failed for Server '...\SQLINSTANCE'. (Microsoft.SqlServer.Smo)
Additional information:
An exception occured while executing a Transact-SQL statement or batch.
(Microfost.SqlServer.ConnectionInfo)
The database 'DatabaseName' cannot be opened because it is version 706. This server supports version 663 or earlier. A downgrade path is not supported.
Could not open new database 'DatabaseName'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 948)
The .mdf was created on SQL Server 2012 (which presumably is represented as 'version 706' in the error message).
OK, so I need to upgrade my DB engine to 2012 on my home PC. That means installing 2012 Express from https://www.microsoft.com/en-gb/download/details.aspx?id=29062
A couple of questions though before I do that. By installing 2012, would it be added to Management Studio 2014 automatically? Would I then have both 2008 & 2012 as options for new databases I might want to create, or would 2012 simply replace 2008?
On the download page, it says the supported OSs are "Windows 7, Windows Server 2008 R2, Windows Server 2008 Service Pack 2, Windows Vista Service Pack 2". But I'm using Windows 10. Is this just a case of MS not updating the page or does 2012 really have a problem with Windows 10?
EDIT: It's true that this question is similar to ones previously asked on SO (such as The database cannot be opened because it is version 706), but here I'm not contemplating rolling back the 2012 version of the DB to 2008, but issues pertaining to installing 2012 on my home PC.
So, your SQL Server version is 2008 - you have 2014 management studio and you need to use a database from a server version 2012.
If that is the case; then I hope some of the following will help:
Windows 10 can run SQL Server 2012 fine.
The documentation might just not be updated, but I've not personally seen any issues on multiple instances.
Management Studio 2014 can connect to SQL Server version 2012 as well. You don't need to install it again.
Unless you wish to remove SQL Server 2008, you'll need to install 2012 as a new instance, so you basically have two SQL Servers running. This however, will have affect on how you connect to the databases.
Check out, for example: https://msdn.microsoft.com/en-us/library/ms143531.aspx for more information
So instead of having multiple instances, consider whether you'll still need 2008, so it might be removed if you don't need it at all.
Also - consider whether it might be worth it to upgrade your local instance to newer version - 2014 for example. However this of course might give you the same problem in reverse in the future, if you ever need to make a database on 2014 instance and move it to a 2012 instance.
It all depends on the actual requirements, set-up and development models. Basically because you say it's your home computer, I'd think the newest version might just be the best approach, as you're less likely to use that version as a "creator" rather than a development version.
I haven't used SQL Server in many years and installed SQL Server 2014 Standard Edition on my Windows 8 development machine today. I'm unable to find the SQL Analyzer tool which from other posts seems to have been renamed to Profiler. What word should I search on to find this application (Windows Search) or is there a simpler way to find it?
I'm not sure if this matters, but I started off with the Express edition of of 2012, couldn't find the tools either and then upgraded to the 2014 Standard Edition.
Thanks in advance.
You need to install SQL server with the install that includes SQL Server Management studio. The Advanced pack contains everything including full text indexing if I remember.
If you've installed the standard edition you might have it already - look for SQL Server Management Studio in your apps.
If not you can download it separately.
SQL Express with Tools is the minimum version that comes with Profiler. That would be the case for both SQL Server (...) 2012 and 2014. There is Profiler for Db Engine and Profiler for Analysis Services and the former is going away after SQL 2016 as described on https://msdn.microsoft.com/en-us/library/ms181091(v=sql.120).aspx
"... announcing the deprecation of SQL Server Profiler for Database Engine Trace Capture and Trace Replay. These features will be supported in the next version of SQL Server, but will be removed in a later version. The specific version of SQL Server has not been determined. The Microsoft.SqlServer.Management.Trace namespace that contains the Microsoft SQL Server Trace and Replay objects will also be deprecated. Note that SQL Server Profiler for the Analysis Services workloads is not being deprecated, and will continue to be supported."
I have an application written in MS ACCESS 2007 using VBA, connecting to an SQL Server at the back end. Both Access and SQL Server are running locally.
My machine runs Access 2010 and MS SQL Server Express 2008 R2 (both 32-bit, on WinXP) with no problem.
I have another machine, Win7 64-bit, running both Access 2010 and SQL Server 2008 (NOT R2) 64-bit.
When I run the Access application on the 64-bit machine, I have a drop down box to select the SQL Server which holds the various databases. When I select the server, after a few seconds I get an error:
Run-time error '-2147024703 (800700c1)':
Automation error %1 is not a valid Win32 application.
When I select the Debug option, the yellow arrow points to:
Set oServer = New SQLDMO.SQLServer
The next line is:
oServer.Connect ServerName, strSQLUser, strSQLPwd
In the watch list, I can see that ServerName, strSQLUser, and strSQLPwd hold the right values to access the SQL Server. I've tested these in sqlcmd and successfully was able to query tables.
Can anyone please help me out on this one? I'm not sure what to do next.
Seems like you've got registered a 32-bit SQLDMO on your system that is being used for connection to the 64-bit instance. Check your registry / file system for SQLDMO.dll versions and register the correct one.
Also check MSDN "Installing SQL-DMO" because SQLDMO was scheduled for remove after SQL Server 2008 R2:
Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
SQL Server Database Management Objects (SQL-DMO) has been removed from SQL Server 2008 R2 Express and the SQL Server 2008 R2 Feature Pack. SQL-DMO also does not support Database Engine features introduced after SQL Server 2000. We recommend that you modify applications that currently use this feature as soon as possible. If you must support SQL-DMO, install the Backward Compatibility Components from the SQL Server 2008 Feature Pack from the Microsoft Download Center. Do not use SQL-DMO in new development work; use SQL Server Management Objects (SMO) instead. You can obtain the SMO documentation by installing SQL Server 2008 R2 Books Online.
Thanks for this.
I looked to find SQLDMO.DLL 64-bit version, but although using the Backwards Comparability package for x64, installing using the MSI did not do the job.
I had to manually extract the files and place the correct version (which is ~2MB larger than the x86 version as an indication to knowing which one is the x64) and then run 'regsvr32 sqldmo.dll ' in the command line (very important: need to run cmd as Administrator for this to succeed).
After the module has been registered, my Access front end run great.
Not that it's a prerequisite for commenting here, but I'd like to pick the brain of someone that's taken their Reporting Services platform from 2000 to 2008 (skipping right over 2005).
The architecture between 2000 and 2005 (so thus between 2000 and 2008 also) changed significantly it seems, so I'd like to know what needs to be done (before,during,after) the process of taking my rs2000 install (installed on a web server running IIS 5, connecting to a remote sql server 2000 box that hosts the ReportServer/ReportServerTempDB databases) and converting it to SQL208 - where, from the looks of it, is hosted in some sort of it's own native hosting engine, no IIS needed (is that right?).
I've used this tool before, but only for moving stuff between 2 rs2000 databases. I'm curious if it works between 2000 and 2008. I've also been reading on TechNet and MSDN about some kind of "upgrade advisor" and "upgrade wizard" - but I remember what the VB6 to VB.NET Wizard was like, so I'm a little skeptical of a wizard that proclaims to help migrate stuff between 2 architecturally different versions of a product.
Disclaimer: I am not a Reporting Services (or SQL Server) admin. Just the guy on the team most familiar with installing/supporting the tool, so I'm stuck being responsible for this migration too - though I'm a veteran developer, not totally clueless.
Be aware, there is no anonymous mode in SRS 2008, you should use Active Directory / Kerberos / Windows authentication or use your own authentication module.
In SRS2008 you've got feature like Tablix/Matrix which are really usefull, maybe you can make some optimizations into your old reports.
I have an application that uses SQLXML to access data on the database. We have it working on a Windows 2003 server and SQL Server 2005. Now the client wants to install it on Windows 2008 and SQL Server 2008 and we are getting errors like:
Microsoft.Data.SqlXml.SqlXmlException: Class not registered ---> System.Runtime.InteropServices.COMException (0x80040154): Class not registered at Microsoft.Data.SqlXml.Common.UnsafeNativeMethods.
ISQLXMLCommandManagedInterface.ExecuteToOutputStream() at Microsoft.Data.SqlXml.SqlXmlCommand.innerExecute(Stream strm)
... etc etc
This is driving me crazy. SQLXML is quite an obsolete technology, and we are trying to use it with the latest SO. I can't find official information about SQLXML and Windows 2008, it seems it's not officially supported but they don't say it's not supported either.
The SQLXML4.0SP1 installation seems to work fine, but it seems like it fails on runtime.
Do you have any ideas? Has someone tried anything like this?
The packages for SQLXML 4.0 SP1 were only available for download in the April 2009 release of the Microsoft SQL Server 2008 Feature Pack. Not sure why they don't appear in the 2008 R2 Feature Pack but they don't.
Here's your link to the Feature Pack
Direct links to the appropriate versions of SQLXML 4.0 SP1 can be found on that page
My recommendation would be to take advantage of the fact that it works on SQL 2005 to convert the code to not use SQLXML. You can take advantage of the fact it works to create tests that prove it works. Then do the conversion, and test again. If the tests still show it works, you've rid yourself of obsolete technology while there's still someone living who knows what the obsolete technology was meant to do.
Otherwise, after finding the fix for this immediate problem (maybe reinstall MSXML) you'll be having this discussion 20 years from now, but with the difference that nobody living knows what SQLXML used to be.
SQLXML is not installed to SQLServer by default. You should run SQL Server Installer, and add SQLXML feature.
I mean SQL Server 2008.
You are probably using ISAPI functionality, which is not supported in SQLXML 4.x
Install SQLXML 3.0 on Win 2008 Server (Vista,7) and for IIS 7.x change IIS 6 Management Compatibilty - allow IIS 6 Metabase Compatibility and IIS 6 Management Console (in Administrative Tools/Server Manager/"Roles - Webserver (IIS)"/ "Role Services" ).
On 64bit Win Server 2008 'Enable 32-bit Applications' for IIS/Application Pools.