The Analysis services project templates are still not available for VS2022 - check that before get rid of 2019, or keep both versions side by side for getting the best of all.
Below we can see a screen snapshot from SSIS, which is on the same situation.
Após expirar sua versão do Reporting Services você não precisa perder nada ou desinstalar o RS atual, mas se você tentar fazer o upgrade diretamente com o instalador ele vai te bloquear e dizer que não é possível, e que você deve tentar uma nova versão. Para evitar o erro siga os passos a seguir:
- Alterar ou remover programas (Programs and ?Features)
- Localizar o Report Services (Microsoft SQL Server Reporting Services)
- Botão direito > Uninstall/Change
- Selecione Upgrade Edition
-
Entre com o product key. Se a tua versão instalada já expirou é provável que esta seja a única opção que vai habilitar o Next.
Observação: Não delete a chave criptográfica mesmo que tenha o arquivo. Se não tiver o arquivo faça o procedimento normalmente porque ele não exige o backup/restore da chave. Somente instalação em novo servidor é que vai exigir a chave se a base de dados, data sources e assinaturas forem originais do servidor anterior.
Se ao executar um comando no SQL Server Management Studio você obtiver um erro com este título então fique atento para o fato que alguns comandos exigem que você use o prefixo N na frente das strings. Eu não tenho o hábito de usar, mas é fato que isso pode causar alguns problemas como este citado. É raro eu ter problemas com isto, mas quando se trata de SP_EXECUTESQL é melhor ficar atento.
O comando EXEC SP_EXECUTESQL 'STRING A EXECUTAR' pode apresentar o erro "O procedimento espera o parâmetro '@statement' do tipo 'ntext/nchar/nvarchar'."
Se isto ocorrer tente EXEC SP_EXECUTESQL N'STRING A EXECUTAR'. Repare que acrescentamos o N antes da String a ser executada. Este é modelo indicado nos manuais o tempo todo, e por isso não é comum ver este erro quem segue o manual à risca.
Bom trabalho.
Vários jobs estavam apresentando o erro abaixo porque a empresa fez uma mudança de domínio do AD e o usuário que havia sido usado para criar os jobs fazia parte do antigo domínio. É o mesmo problema que ocorre quando se exclui um usuário do AD e recria com o mesmo nome. O usuário existe mas não é o mesmo. Neste caso ele realmente ainda existe, mas o domínio está fora de uso ou de alcance, sem responder às requisições de permissões (ou similar). Não adiantou trocar o owner do job diretamente na interface, apesar de isso parecer mais que suficiente. Somente depois que peguei uma dica do mestre Pinal Dave é que a coisa começou a melhorar, embora não tenha sido suficiente para tudo.
Outra ação que fiz foi, segundo uma fonte que agora não lembro, fazer um Detach e Attach usando o SA user database para refazer todos os logons (se é que isso serviu, mas eu fiz).
Message: The job failed. Unable to determine if the owner (domain\user) of job <job name> has server access (reason: Could not obtain information about Windows NT group/user 'domain\user', error code 0x6fc. [SQLSTATE 42000] (Error 15404)). NOTE: Failed to notify 'Alexandre Paiva' via email.
USE MSDBGOUPDATE sysssispackagesSET ownersid = SUSER_SID('sa')WHERE NAME = 'Name Of Maint Plan'No meu caso, como tudo estava quebrado, eu não usei o WHERE. Que luxo poder rodar um Update sem Where. Tome cuidado.
Dentre os vários possíveis erros para esta mensagem uma delas que acabei tendo que enfrentar esta semana foi que o @@ServerName estava apontando para o antigo nome do servidor que foi virtualizado. Após horas de investigação e muitas tentativas de outras soluções finalmente cheguei à causa raiz do problema, o bendito server name desatualizado.
Message [382] Logon to server 'servername' failed (ConnLogJobHistory)
O SQLServerAgent tentava se autenticar ou algo parecido no nome antigo. Como isto não era mais possível os Jobs simplesmente não executavam. Dava o start, mas nada, até cair por timeout
Após aplicar os comandos a seguir foi necessário apenas reiniciar os serviços, deconectar da instância e reconectar no Management Studio.
EXEC sp_dropserver '<old_name>'; GO EXEC sp_addserver '<new_name>', local; GO
The jobs are running. Shout to the Lord.
Se você está com problemas ao criar assinatura para os relatórios no Reporting Server uma permissão pode resolver o problema. Inclua a conta do ReportingServices na role SysAdmin.
Depois de 2 dias pesquisando sobre o problema eu achei um paper da MS sobre a versão 2012 que resolveu meu problema.
Security
NT SERVICE\SQLServerReportingServices > Roles > sysadmin
Since I've changed from SSMS 17 to 18 my life becomes harder. It's a shame to get a hole new tool, based on a superb successful previous version and have bad times all the time. Yes, I love the improvements, but I missed very hard the absence of the Debug feature inside SSMS 18.
But this is not the only question: frequently I have some problem wich the solution is to reinstall the older version to fix it. Now I've the Integration Service stop responding on a server after I upgraded the SSMS to 18.x. The only solution I coud find googling was: downgrade your version of SSMS to 17 and be happy.
What will I do?
Donwloading SSMS 17 in progress... (21%)
Shame on you Microsoft, my beloved Microsoft.