I have a silent installation of SQL Server 2005 that works great when installing SQL Server on a machine that does not have it already installed. I use the following parameters when I perform the installation:
#define SQL_SILENT "/passive /qb"
#define SQL_USERNAME "username=MyUserName"
#define SQL_COMPANYNAME "companyname=MyCompanyName"
#define SQL_ADDLOCAL "ADDLOCAL=SQL_Engine"
#define SQL_UPGRADE ""
#define SQL_DISABLENETWORKPROTOCOLS "disablenetworkprotocols=0"
#define SQL_INSTANCENAME "instancename=MYSQLINSTANCE"
#define SQL_SQLAUTOSTART "SQLAUTOSTART=1"
#define SQL_SECURITYMODE "SECURITYMODE=SQL"
#define SQL_SAPWD "SAPWD=StrongPassword"
#define SQL_SQLACCOUNT "SQLACCOUNT="""""
#define SQL_SQLPASSWORD "SQLPASSWORD="""""
It installs the instance of SQL Server Express without a problem. However, when I attempt to install SQL Server on a machine that already has another instance with components I get the following error:
"A component that you have specified in the ADD_LOCAL property is already installed. To upgrade the existing component, refer to the template.ini and set the UPGRADE property to the name of the component."
I have also tried using the UPGRADE method as per the error message
#define SQL_UPGRADE "UPGRADE=SQL_Engine INSTANCENAME=MYSQLINSTANCE"
but get the following error:
"SQL Server Setup cannot perform the upgrade because the component is not installed on the computer. To proceed, verify the component to be upgraded in currently installed, and that the component to be upgraded is specified in the ADDLOCAL property."
Does anyone have any suggestions?
Are you sure the server name / instance name are correct?
What do you see in the registry, specifically
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL
and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\Machines
I define the Instance Name in a single place and re-use it to avoid mis-typing it elsewhere.
You manually remove the workstation components from Add/Remove programs and install it
I had a similar issue when I tried to install Management Studio on top of an existing SQL 2005 installation. The cause of this problem for me was that I had the SQL Express tools installed. Since they did not show up under Add/Remomve Programs, I uninstalled them using a Microsoft tool I downloaded called "Windows Install Clean Up". After doing this, I was able to install the SQL 2005 client tools (Management Studio, etc.) by running SqlRun_Tools.msi directly from the CD.
Related
I am having a problem with using Apache/Perl to get access to Excel files using Microsoft Data Access Component (MDAC). Somehow I must set the "CommonProgramFiles(x86)" system environment variable in order to get this to work. Otherwise, I keep getting this error message:
System.InvalidOperationException: The .Net Framework Data Providers
require Microsoft Data Access Components(MDAC). Please install
Microsoft Data Access Components(MDAC) version 2.6 or later. --->
System.IO.FileNotFoundException: Retrieving the COM class factory for
component with CLSID {2206CDB2-19C1-11D1-89E0-00C04FD7A829} failed due
to the following error: 8007007e.
The server configuration is:
Windows Server 2008 R2 in 64-bit
Server is installed with Microsoft Access Database Engine 2010
Apache 2.2.25 (that is 32-bit)
Perl 5.12.3 v5 (that is also in 32-bit)
I have my Perl CGI script to call my C# program (that is built for "Any CPU").
The C# program uses MDAC to open and read Excel files (not trying to launch Excel, only try to read data from the Excel files).
I have verified that the server has the latest MDAC available in these 2 folders:
C:\Program Files\Common Files\System\Ole DB
C:\Program Files (x86)\Common Files\System\Ole DB
I have also checked the registries and they look fine. Anyway, I don't have any problem running my C# program directly at the command prompt (it can use MDAC to get access to Excel files). I only have the problem when I use Apache/Perl to use my Perl CGI script to call my C# program (that is when I get that error with MDAC).
I can work around this problem by specifying CommonProgramFiles(x86) in my Perl CGI script, like this:
$ENV{ "CommonProgramFiles(x86)" } = "C:\\Program Files (x86)\\Common Files";
I have this question:
Why do I have this problem? And why setting that CommonProgramFiles(x86) system environment variable can workaround this problem? Why that system environment variable is empty before I set it? Does this have to do with the fact that I am running 32-bit Apache/Perl in a Windows operating system that is 64-bit?
Please help me to understand this issue. Thanks in advance.
(The original version of this post had a question about a second problem. Turned out that problem had to do with an extra double quote in the string. I fixed this, and that problem has gone away. That's why I have removed that second question from the post)
Jay Chan
I did some more research and the issue is the following: until release 2.4.9, the Apache startup routines have mapped "commonprogramfiles(x86)" to "commonprogramfiles_x86_" and that variable does not exists in the environment unless you create it... I have not tested it, but creating that environment variable and making it point to the same location as commonprogramfiles(x86) would probably fix the issue too.
Since the compiled Apache distributions are only using up to version 2.4.46 as we speak, they don't have the fix that allows the parenthesis in environment variables. That's why you still need the PassEnv directive to ensure that Apache passes the correct values to 32-bit CGI scripts.
The following post has some useful details about this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=46751
I used to have the same problem in with Apache 2.4 with dBase compiled apps using ADO-32 bit as dBase is 32-bit. Something has recently changed, possibly with Windows 10 2004 20H2. I needed this fix in July-Aug 2020 but now I don't, the environment variable already exists. Since my Apache version is dated April 2020, that cannot be the reason for the change.
I tried to do some research about this but all I could find is that those environment variables are system ones existing at least since 2017, so why I needed to set this var is a mystery to me, but I would like to understand this, so if you find something, post a follow-up...
https://learn.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables
As mention in Orafce Install.orafunc:
..install Orafce functions in the database, either run the orafce.sql script using the pgAdmin SQL tool..
I tried running the orafce--3.0.sql in pgAdmin sql editor. This give me error
ERROR: could not access file "MODULE_PATHNAME": No such file or directory.
What do you mean by module path?
Installed program:
strawberry perl with DBD::Oracle
postgresql 9.3
pgAdmin III
Not fully installed:
ora2pg
I tried installing ora2pg...with a problem.
H:\PostgreSQL\ora2pg-12.1>perl makefile.pl
Unparsable version '' for prerequisite DBD::Oracle at makefile.pl line 553
Generating a dmake-style Makefile
Writing Makefile for Ora2Pg
Writing MYMETA.yml and MYMETA.json
Done...
H:\PostgreSQL\ora2pg-12.1>dmake && dmake install
"Installing default configuration file (ora2pg_dist.conf) to C:\ora2pg"
Appending installation info to C:\strawberry\perl\lib/perllocal.pod
dmake: Warning: -- Target [install] was made but the time stamp has not been up
dated.
Suggested Solution:
I downloaded a copy of orafce from okbob github
Unzip the file to folder D:/Postgresql/orafce-master
I copy only the following files
orafce--unpackaged--3.0.6.sql
orafce--3.0.6.sql
orafce.control
to folder C:\Program Files\PostgreSQL\9.3\share\extension
Then I try running this command in pgAdmin III sql tools.
CREATE EXTENSION orafce;
I received this Warning and Error.
[WARNING ] CREATE EXTENSION orafce
ERROR: syntax error in file "C:/Program Files/PostgreSQL/9.3/share/extension/orafce.control" line 1, near end of line
I checked orafce.control content. It has this config.
# intarray extension
comment = 'Functions and operators that emulate a subset of functions and packages from the Oracle RDBMS'
default_version = '3.0.6'
module_pathname = '$libdir/orafunc'
relocatable = false`
I can't pass to this wall. What seems the problem?
So, you are working with source raw files. You should to compile these files first - and later you can use it. It is relative simply on Unix like platforms, where C compiler is usually available, and pretty hard on MS Windows, where you have to install C compiler first.
I afraid so we lost pgFoundry archive, where was orafce precompiled and packed.
Almost all Linux distributions support orafce directly - and you can install it without compilation from repositories.
see http://wiki.postgresql.org/wiki/Building_and_Installing_PostgreSQL_Extension_Modules
$libdir is symbol, that is used for PostgreSQL extensions directory. It can be different for any platform - and it is replaced inside compilation stage by actual value. MODULE_PATHNAME has similar meaning. In compilation stage is replaced by valid actual path to library with compiled code.
I am sorry - we don't provide a compiled files - mainly due high risk for MS Windows. We have no forces, and tools to maintain all Win safely. In this moment, you can:
try to contact someone who use orafce for windows for backup of orafce installers
try to compile this extension by self (Microsoft Visual Studio Express edition is free and downloadable on internet).
other possibility is migrate database server to Linux - almost all database maintenance and usage is more simply and more robust there (due missing viruses, antiviruses and less resource requests). The Linux is primary platform for Oracle too.
some tutorials:
http://blog.2ndquadrant.com/compiling-postgresql-extensions-visual-studio-windows/
http://www.scribd.com/doc/40725510/Build-PostgreSQL-C-Functions-on-Windows
We are trying to deploy a database project using tfs deployer and "vsdbcmd.exe" (VS 2010 version).
Both are on a windows server 2008 r2 (64 bit).
When our deployment script runs and we call the VSDBCMD.exe, we get the following error:
An unexpected failure occurred: Object reference not set to an instance of an object.
Note: SQL Server is not installed on this server, the script calls to a different server which has the databases we want to execute the database schemas against. Visual studio is also not installed on this server so I executed reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0 as I found a missing registry key could be causing the issue. However, the problem still occurs
The dll's copied to the server are:
Extensions (folder)
DatabaseSchemaProviders.Extensions.xml
Microsoft.Data.Schema.dll
Microsoft.Data.Schema.ScriptDom.dll
Microsoft.Data.Schema.ScriptDom.Sql.dll
Microsoft.Data.Schema.Sql.dll
Microsoft.Data.Schema.Utilities.dll
Sqlceer35en.dll
Sqlceme35.dll
Sqlceqp35.dll
Sqlcese35.dll
sqlceca35.dll
sqlcecompact35.dll
sqlceoledb35.dll
System.Data.SqlServerCe.dll
vsdbcmd.exe
vsdbcmd.exe.config
Any ideas on how to resolve this would be great
Thanks,
Ryan
Background:
I have several builds running on a Windows Server 2003 R2 machine via TFS2010. All of these build definitions have the Path to Publish Symbols set to "\\server\SymbolStore" and the builds run fine.
(Note - I have inherited this set up from a former employee, and I also have other builds running on a separate 2K8 machine that also run without issue)
I am now migrating these builds to a new Windows 2008 R2 build server using the same settings.
Problem:
When running the builds on the new build machine, everything is working fine until the build tries to run the "Publish Symbols" activity in the workflow, at which point I get the error
SYMSTORE ERROR: Class: Server. Desc: Couldn't connect to server.
Error 5: Access is denied. TF270015: 'symstore.exe' returned an
unexpected exit code. Expected '0'; actual '5'.
which also sets the build status to Partially Succeeded.
I have searched the web for these error messages to no avail so far, so does anyone know what might be causing this and how to get it working again?
As always, thanks in advance
Did you check the folder has the right permissions for the service account that is used by Team Build to create/write files ?
Turns out that after I had set up the new build machine, I had left the Credentials for the Build Service Properties (found in the Team Foundation Server Administration Console/Build Configuration) to its default setting which is "NT AUTHORITY\NetworkService". Once I had changed this to use the build service account, the builds are able to write to the symbol store properly
I need to set up an instance of SQL Server 2005 with SQL_Latin1_General_CP850_Bin as the server collation (the vendor did not take into accounting looking at DB collation for a bunch of things so stored procedures and temp tables default to the server level and the default collation will not work). During the install for SQL Server it did not give that as an option so I left it at default and finished installing it.
According to MSDN and Technet I should need to just run the following command:
setup.exe /q /ACTION=RebuildDatabase /INSTANCENAME=MSSQLSERVER /SAPWD="sa-pwd" /SQLSYSADMINACCOUNTS="BUILTIN\ADMINISTRATORS" /SqlCollation=SQL_Latin1_General_CP1_CI_AI
However, whenever I run the above command with my parameters I get the pop-up of the SQL Server installation wizard, accept the agreement, and then it gives me output stating how to use the command.
Any idea what I can do?
I think you're looking at instructions for SQL Server 2008.
See the article here for instructions for 2005.
If possible, I would uninstall and reinstall rather than trying to change it. Changing it without re-installing is not a simple process. To change from the default during install, just uncheck the "Hide advanced configuration options" check box on the Registration Information screen; doing that will give you a Collation Settings option about 4 screens later in the install.