I am trying to get the Zumero for SQL Server working and I cannot get past running the test client. I get the below error
Connection string in web.config is
<settings temp_directory="C:\ProgramData\Zumero\ZSS Server\temp\"
odbc_connection_string="DSN=krishna;User Id=syncadmin;Password=syncadmin;"
license_key="<removed>" />
The description for Event ID 1 from source Zumero cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
Error -1 (mssql): {"diag":[{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot open database \"ZumeroTest\" requested by the login. The login failed.","SQL_DIAG_NATIVE":4060,"SQL_DIAG_SQLSTATE":"42000"},{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed","SQL_DIAG_NATIVE":0,"SQL_DIAG_SQLSTATE":"IM006"},{"SQL_DIAG_MESSAGE_TEXT":"[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute","SQL_DIAG_NATIVE":0,"SQL_DIAG_SQLSTATE":"01S00"}],"SQLRETURN":-1}
..\..\..\src\core\sg\sg_mssql.c:344
..\..\..\src\core\sg\sg_mssql.c:384
..\..\..\src\core\server\zum_db_mssql.c:2896
..\..\..\src\core\server\zum_respond.c:4454
..\..\..\src\servers\iis\main.cpp:1211
The publisher has been disabled and its resource is not avaiable. This usually occurs when the publisher is in the process of being uninstalled or upgraded
Either the SQL Server user doesn't have rights or the database doesn't exist.
You can use a DSN, but for troubleshooting purposes I recommend putting the connection details directly in the connection string for now. Once it's working you can migrate the settings back to a DSN if you like.
Looks like you're using SQL Server authentication. So the odbc_connection_string value should look like this:
Driver={SQL Server Native Client 11.0};Database={database};Server={server.ad.domain.com};UID={sql_server_user};PWD={password};
The database must exist and the user specified must have appropriate read/write access to it.
(If you're setting minimum necessary permissions, you'll also want to make sure the user has VIEW SERVER STATE rights, as described here.)
While unrelated to your invalid connection string problem, the messages about The description for Event ID 1 [...] and The publisher has been disabled [...] indicate that ZSS hasn't been correctly registered with the Windows Event Viewer. Did you install the server by hand (from the .zip file) or using the installer?
You can fix those messages using the following command (which probably requires an admin prompt):
wevtutil im "PATH\TO\events.man" /rf:"PATH\TO\zumero_server.dll" /mf:"PATH\TO\zumero_server.dll"
where PATH\TO is the path where you extracted those files from the .zip. If you used the installer then they should be located at: %PROGRAMFILES%\Zumero\ZSS Server
If you installed manually from the .zip then it's worth noting that the instructions had a subtle typo in that command which would cause it to fail. That typo has been fixed in the past few days, but it may have caught you during your installation and caused this issue.
Related
I have a BizTalk 2013r2 Standard Edition application server with CU7 installed. The BizTalk databases are hosted on a separate Sql Server 2014 server. This setup has been working fine for many months - until today! A colleague used the BizTalk admin console to make a change to the address BizTalk uses to the reach the SMTP server, by selecting Platform Settings\Adapters\SMTP\\properties.
After making this change, on attempting to refresh the BizTalk Admin Console, the following error is displayed:
From what I've googled, it seems this may be due to some corruption in the SSO database. I have a backup of the SSO database, and a backup of the SSO key along with the password. Before restoring the backup of the SSO database, I wanted to check that I would be able to restore the key, so I ran ssoconfig -restoreSecret from the command line. I was prompted to enter the password. If I intentionally enter the wrong password then it tells me the password is incorrect. However, if I enter the correct password then it displays the message "BAD DATA".
Although the BizTalk admin console is currently unusable, thankfully the BizTalk host instance continue to run and messages are being processed as expected.
Can anyone please suggest why I'm getting the "BAD DATA" message, or perhaps a work-around in order to solve the problem?
I had this problem again and blogged about it at BizTalk WinMgt error solution. As Colin says the hard part is identifying the corrupt handler. It is probably the SMTP send handler but you should check this using WBEMTEST first. I found this link helpful on using WBEMTest. The parameter is incorrect (WinMgt)" error when refreshing the BizTalk Group in BizTalk Administration Console
In my case a quick fix to bring the BizTalk Administration Console back to life was to hack the database. N.B. This probably won't be supported by MS. In my case it was the FTP send handler that screwed up. So I ran
USE [BizTalkMgmtDb]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[adm_SendHandler2_Delete]
#AdapterName = N'FTP',
#HostName = N'Sending32'
SELECT 'Return Value' = #return_value
GO
At this point the BizTalk Administration console came back to life. In my case it worked because I was creating a new handler but in your case you just edited it. It will take all your SMTP handling out.
I then fixed the corruption using the BizTalk Administration console.
In my case I had to set every FTP receive and send adapter temporarily to a FILE adapter.
I then deleted the FTP adapter and then re-added it. Finally I reset the all the change receive and send location from FILE back to FTP.
This was all very scary on a live system.
Finally I believe that this is bug in BizTalk 2013 R2 because I've seen it happen on 2 systems and now I have heard that the same thing happened to you.
The WinMgt error happens when one of the Adapters setting has gotten itself corrupted. See WinMgt error when refreshing Group Hub
Removing and re-adding the adapter to the host usually fixes it. The trick of course is identifying which Adapter / Host, I would start with the SMTP adapter in your case.
I try to setup an OpenLDAP-Server that I can use as backend for a WebSSO (LemonLDAP::NG). This specific WebSSO allows to store the sessions inside the LDAP backend.
My problem is that it seems that whenever I connect to the LDAP backend to store session data ~1 out of 10 times it works, the other times LDAP rejects the authentication.
Logs for failed attempts and for successful attempts can be found here
As you can see the maker of LemonLDAP::NG thinks the error is within OpenLDAP (or my configuration of OpenLDAP). I'm out of ideas and open to suggestions.
Looks like someone changes OpenLDAP DB during your session. Don't you have any processes with access to MDB file except this instance of OpenLDAP?
It may be slapadd/slapmodify/2nd slapd instance with the same directory value in config.
If not, could you show your slapd.conf (don't forget to change rootpw)
I had (by mistake) a copy of an update site on one server. I had the correct copy on another server so I replicated it to the first server and deleted the original bad update site DB. I found the entry OSGI_HTTP_DYNAMIC_BUNDLES= in the Notes.ini that was pointing to the update DB that I deleted, so I changed it to the new database name, shut down the server and then restarted it. and I get the following error
08/05/2014 12:41:38 PM HTTP JVM: NotesException: Invalid replica id (WFSUpDat.nsf)
where WFSUpDat.nsf is the old (wrong) update site. So Domino is storing this information somewhere else. Can someone give me a pointer as to where it is.
Also if I use the command line
tell http osgi ss com.ibm,xsp.extlib
I get a list of the installed extension library, I have the debug toolbar 4.01 installed in the update site what would the command line be to get the same thing to confirm the version of the toolbar?
Thanks
Make the change in the Server Configuration document in the Server Names.nsf, not directly in the Notes.ini
Should know better, but .......
I am learning how to use the Service Broker of SQL Server 2008 R2. When following the tutorial Completing a Conversation in a Single Database. Following the Lesson 1, I have successfully created the message types, contract, the queues and services. Following the Lesson 2, I have probably sent the message. However, when trying to receive the message, I get the NULL for the ReceivedRequestMsg instead of the sent content.
When looking at the sys.transmission_queue, the transmission_status for the message says:
An exception occurred while enqueueing a message in the target queue. Error: 15517, State: 1. Cannot execute as the database principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
I have installed SQL Server using the Windows login like Mycomp\Petr. I am using that login also for the lessons.
Can you guess what is the problem? What should I check and or set to make it working?
Edited 2012/07/16: For helping to reproduce the problem, here is what I did. Can you reproduce the error if you follow the next steps?
Firstly, I am using Windows 7 Enterprise SP1, and Microsoft SQL Server 2008 R2, Developer Edition, 64-bit (ver. 10.50.2500.0, Root Directory located at C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL_PRIKRYL05\MSSQL).
Following the tutorial advice, I have downloaded the AdventureWorks2008R2_Data.mdf sample database, and copied it into C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL_PRIKRYL05\MSSQL\DATA\AdventureWorks2008R2_Data.mdf
The SQL Server Management Studio had to be launched "As Administrator" to be able to attach the data later. Then I connected the SQL Server.
Right click on Databases, context menu Attach..., button Add..., pointed to AdventureWorks2008R2_Data.mdf + OK. Then selected the AdventureWorks2008R2_Log.ldf from the grid below (reported as Not found) and pressed the Remove... button. After pressing OK, the database was attached and the AdventureWorks2008R2_log.LDF was created automatically.
The following queries were used for looking at "Service Broker enabled/disabled", and for enabling (the Service Broker was enabled successfully for the database):
USE master;
GO
SELECT name, is_broker_enabled FROM sys.databases;
GO
ALTER DATABASE AdventureWorks2008R2
SET ENABLE_BROKER
WITH ROLLBACK IMMEDIATE;
GO
SELECT name, is_broker_enabled FROM sys.databases;
GO
Then, following the tutorial, the queries below were executed to create the message types, the contract, the queues, and the services:
USE AdventureWorks2008R2;
GO
CREATE MESSAGE TYPE
[//AWDB/1DBSample/RequestMessage]
VALIDATION = WELL_FORMED_XML;
CREATE MESSAGE TYPE
[//AWDB/1DBSample/ReplyMessage]
VALIDATION = WELL_FORMED_XML;
GO
CREATE CONTRACT [//AWDB/1DBSample/SampleContract]
([//AWDB/1DBSample/RequestMessage]
SENT BY INITIATOR,
[//AWDB/1DBSample/ReplyMessage]
SENT BY TARGET
);
GO
CREATE QUEUE TargetQueue1DB;
CREATE SERVICE
[//AWDB/1DBSample/TargetService]
ON QUEUE TargetQueue1DB
([//AWDB/1DBSample/SampleContract]);
GO
CREATE QUEUE InitiatorQueue1DB;
CREATE SERVICE
[//AWDB/1DBSample/InitiatorService]
ON QUEUE InitiatorQueue1DB;
GO
So far, so good.
Then the following queries are used to look at the queues (now empty when used):
USE AdventureWorks2008R2;
GO
SELECT * FROM InitiatorQueue1DB WITH (NOLOCK);
SELECT * FROM TargetQueue1DB WITH (NOLOCK);
SELECT * FROM sys.transmission_queue;
GO
The problem manifests when the message is sent:
BEGIN TRANSACTION;
BEGIN DIALOG #InitDlgHandle
FROM SERVICE
[//AWDB/1DBSample/InitiatorService]
TO SERVICE
N'//AWDB/1DBSample/TargetService'
ON CONTRACT
[//AWDB/1DBSample/SampleContract]
WITH
ENCRYPTION = OFF;
SELECT #RequestMsg =
N'<RequestMsg>Message for Target service.</RequestMsg>';
SEND ON CONVERSATION #InitDlgHandle
MESSAGE TYPE
[//AWDB/1DBSample/RequestMessage]
(#RequestMsg);
SELECT #RequestMsg AS SentRequestMsg;
COMMIT TRANSACTION;
GO
When looking at the queues, the Initiator... and the Target... queues are empty, and the sent message can be found in sys.transmission_queue with the above mentioned error reported via the transmission_status.
alter authorization on database::[<your_SSB_DB>] to [sa];
The EXECUTE AS infrastructure requires dbo to map to a valid login. Service Broker uses the EXECUTE AS infrastructure to deliver the messages. A typical scenario that runs into this problem is a corporate laptop when working from home. You log in to the laptop using cached credentials, and you log in into the SQL using the same Windows cached credentials. You issue a CREATE DATABASE and the dbo gets mapped to your corporate domain account. However, the EXECUTE AS infrastructre cannot use the Windows cached accounts, it requires direct connectivity to the Active Directory. The maddening part is that things work fine the next day at office (your laptop is again in the corp network and can access to AD...). You go home in the evening, continue with Lesson 3... and all of the sudden it doesn't work anymore. Make the whole thing seem flimsy and unreliable. Is just the fact that AD conectivity is needed...
Another scenatio that leads to the same problem is caused by the fact that databases reteint the SID of their creator (the Windows login that issues the CREATE DATABASE) when restored or attached. If you used a local account PC1\Fred when you create the DB and then copy/attach the database to PC2, the account is invalid on PC2 (it is scoped to PC1, of course). Again, not much is affected but EXECUTE AS is, and this causes Service Broker to give the error you see.
And last example is when the DB is created by a user that later leaves the company and the AD account gets deleted. Seems like revenge from his part, but he's innocent. The production DB just stops working, simply because it's his SID that the dbo maps too. Fun...
By simply changing the dbo to sa login you fix this whole EXECUTE AS thing and all the moving parts that depend on it (and SSB is probably the biggest dependency) start working.
You would need to grant receive on your target queue to your login. And it should work!
USE [YourDatabase]
GRANT RECEIVE ON [dbo].[YourTargetQueue]
TO [Mycomp\Petr];
GO
And you also need to grant send for your user, permission on Target Service should be sufficient, but let's enable on both services for the future.
USE AdventureWorks2008R2 ;
GO
GRANT SEND ON SERVICE::[//AWDB/1DBSample/InitiatorService]
TO [Mycomp\Petr] ;
GO
GRANT SEND ON SERVICE::[//AWDB/1DBSample/TargetService]
TO [Mycomp\Petr] ;
GO
The context is OLAP cube development. After configuring my project though SQL Server Data Tools (SSDT, the new BIDS) I am unable to deploy the project.
Every time the deployment process is started I get an error like the one below:
File system error: The following error occurred while opening the file '\\?\D:\[...]\database\mssql\tmpdb\MDTempStore_1864_9_no8wd.tmp': Access is denied.
(The [...] denotes some part of the path I ommited for brievty)
I always get the same error, indicating that some .tmp file could not be accessed.
My environment:
OS: Windows Server 2008 R2 Standard, SP1
SQL Server: SQL Server 2012 (v11.0.2100.60), running on localhost
What I tried:
I have the File System access rights for the folder in question (at some point I even tried with Admin privileges on the machine, didn't help)
I tried to deactivate the anti-virus in case it was performing on-access-scan (still didn't help)
Attempts to deploy/process individual dimensions causes the same problem
Deploying dimensions or cubes programmatically through SMO (instead of SSDT) runs into the same problem
Deploying DataSource objects as well as DataSourceView objects works fine
Maybe some of you faced similiar issues or have further suggestions/ideas?
Thanks for you help!
So, I finally figured it out.
As expected it was a permission issue, but despite the error message hinting at some missing file system permissions, the cause of the problem was the user I configured the Data Source with.
The SQL User I specified was given the roles
db_datareader
db_datawriter
db_ddladmin
on the source database but this doesn't seem to be enough. When I tried to give him the server role sysadmin it started working.
This is probably overkill, one could further fine-tune the role assignment but for now it also works that way.
Just a suggestion here - have you tried running SSDT as an administrator? That is, right-click on SSDT and click Run As Administrator. Then try to deploy your project. It definitely sounds like a permissions issue.
Exact reason is SSAS Service user does not have an access to the folders that are specified in SSAS configuration (i.e error states it is Temp Folder). I think it is not directly related with SQL Server because it is just a file access error. Error is thrown before it reaches SQL Server.
Give full permission to SSAS Service User for those folders.
Regards
Onur