My LOCAL, DEV & PROD servers are at v 2017 but the databases are at compatibility level 2012 (110).
A co-worker claims he's having issues getting latest as STRING_AGG is not supported. I'm going to assume he is running something lower than SSMS 2017
I assumed I'd have to up the compatibility level before deployment but that does not seem to be the case.
Why does this work? Is this an unsupported "feature"?
My DEV server version is 2017 and the compatibility_level is 110
DROP TABLE IF EXISTS test
CREATE TABLE test (id int IDENTITY(1,1), dt date DEFAULT(GETDATE()), theData VARCHAR(20) NULL)
INSERT INTO [dbo].[test]([theData])
VALUES(NULL),('some data'),('old data'),(NULL)
SELECT STRING_AGG(t.[theData],', ') [testing string_agg method]
FROM [dbo].[test] AS [t]
Related
how can I select the id of current connection and the server Version in Interbase 2022?
In Firebird I can use this SQL to select the Serverversion:
SELECT rdb$get_context('SYSTEM', 'ENGINE_VERSION') as version from rdb$database
And I have "current_connection" to get the ID of the current connection.
I'm lookig for something like that for Interbase 2020.
Regards
This command:
liquibase --logLevel=off --changeLogFile=./database_change_log.xml --url='offline:postgresql?outputLiquibaseSql=true' updateSql > database_up.sql
generates this:
Starting Liquibase at Thu, 14 Mar 2019 11:29:12 CDT (version 3.6.3 built at 2019-01-29 11:34:48)
-- *********************************************************************
-- Update Database Script
-- *********************************************************************
-- Change Log: ./database_change_log.xml
-- Ran at: 3/14/19, 11:29 AM
-- Against: null#offline:postgresql?outputLiquibaseSql=true
-- Liquibase version: 3.6.3
-- *********************************************************************
CREATE TABLE databasechangelog (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED TIMESTAMP WITHOUT TIME ZONE NOT NULL, ORDEREXECUTED INTEGER NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10));
-- Changeset ./database_change_log.xml::1::Jim Barrows
CREATE TABLE topic (id UUID NOT NULL, name VARCHAR(100) NOT NULL, description TEXT, CONSTRAINT TOPIC_PKEY PRIMARY KEY (id));
INSERT INTO databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1', 'Jim Barrows', './database_change_log.xml', NOW(), 1, '8:7b01de4dcdab4ed25f79ce192ba538f6', 'createTable tableName=topic', '', 'EXECUTED', NULL, NULL, '3.6.3', '2580954069');
Liquibase command 'updateSql' was executed successfully.
The problem is that I don't want the "Starting liquibase" or success lines in the SQL.
Note: off is from the docs: --logLevel= Execution log level (debug, info, warning, severe, off).
I've tried to use "severe" & "error" as well
This is version 3.6.3, and version 3.5.3 does not do this. How do I fix this?
Someone has already opened a bug ticket for this: https://liquibase.jira.com/browse/CORE-3342.
This seemingly got introduced from version 3.6 on.
EDIT:
So maybe downgrade or even better propose a fix in form of a pull request. :-)
Wondering about why updateSQL output would be written with a logging framework
I just discovered that you could pass in migrationSqlOutputFile as a parameter instead of redirecting the standard output to a file. That way the logging should not be mingled with output from updateSQL.
(Have not tried this though.)
Use --outputFile option in the liquibase command to direct the sql statements to a file. I use liquibase version 3.7.0 and this option works.
Since 3.4.0 release of Liquibase, you can use outputFile flag. Details are here:
https://www.liquibase.org/2015/07/without-a-connection.html
I have been experimenting using the code below and it seems it does not work.
DBCC TRACEON (460);
DECLARE #aa as TABLE (name varchar(5))
INSERT INTO #aa
SELECT '1234567890'
Error
String or binary data would be truncated
Expected error:
String or binary data would be truncated in table #aa, column name. Truncated value: '1234567890'
According to https://www.procuresql.com/blog/2018/09/26/string-or-binary-data-get-truncated/ SQL Sever 2019 will be able to identify the columns that have been truncated, but can be used in SQL Server 2016 using TRACEON 460.
In terms of roles, I have "public", "processadmin", and "sysadmin".
In the sys.messages I think the patch for this feature based on message_id=2628:
+------------+------------------------------------------------------------------------------------------------------+
| message_id | text |
+------------+------------------------------------------------------------------------------------------------------+
| 2628 | String or binary data would be truncated in table '%.*ls', column '%.*ls'. Truncated value: '%.*ls'. |
| 8152 | String or binary data would be truncated. |
+------------+------------------------------------------------------------------------------------------------------+
Details:
Microsoft SQL Server 2016 Standard (64-bit)
Version : 13.0.5149.0
Is Clustered : False
Is HADR Enabled : False
Is XTP Supported : True
The new error message hasn't yet been back-ported to SQL Server 2016. From this post (emphasis mine):
This new message is also backported ... (and in an upcoming SQL Server 2016 SP2 CU) ...
This CU has not been delivered yet. The most recent, CU5 (13.0.5264.1), was released in January and did not include it.
And just a small correction, you need to opt in to this behavior (via the trace flag) even in the SQL Server 2019 CTPs. The reason is that a different error number is produced, and this could break existing applications and unit tests that behave based on the error number raised. This will be documented as a breaking change when SQL Server 2019 is released, but I'm sure it will still bite some people when they upgrade.
I am creating Application server in Worklight 6.1 in server with WL db as DB2 which throws below error and fails with the build. The DB2 error mentioned is increase the pagesize of DB2 database. But how to increase the pagesize in DB2.
[configuredatabase] [sql] SQL: CREATE TABLE APP_ACTIVITY_REPORT (ID BIGINT NOT NULL, ACTIVITY CLOB(1M), ACTIVITY_TIMESTAMP TIMESTAMP, ADAPTER VARCHAR(254), DEVICE_ID VARCHAR(254), DEVICE_MODEL VARCHAR(254), DEVICE_OS VARCHAR(254), ENVIRONMENT VARCHAR(254), GADGET_NAME VARCHAR(254), GADGET_VERSION VARCHAR(254), IP_ADDRESS VARCHAR(254), PROC VARCHAR(254), SESSION_ID VARCHAR(254), SOURCE VARCHAR(254), USER_AGENT VARCHAR(254), LONGITUDE DOUBLE, LATITUDE DOUBLE, POS_USER_TIME TIMESTAMP(3), WIFI_APS VARCHAR(4000), WIFI_CONNECTED_SSID VARCHAR(32), WIFI_CONNECTED_MAC CHAR(20), WIFI_USER_TIME TIMESTAMP(3), APP_CONTEXT VARCHAR(4000), PRIMARY KEY (ID))
[configuredatabase]
BUILD FAILED
[configuredatabase] C:\Users\ADMINI~1\AppData\Local\Temp\wla6314449573\configure.xml:1927: The following error occurred while executing this line:
[configuredatabase] C:\Users\ADMINI~1\AppData\Local\Temp\wla6314449573\configure.xml:3236: com.ibm.db2.jcc.am.SqlSyntaxErrorException: DB2 SQL Error: SQLCODE=-286, SQLSTATE=42727, SQLERRMC=16384;ADMIN, DRIVER=4.13.127
The instructions for creating the worklight database with the 32K pagesize are at this link . The Worklight version is higher but the Db2 details for creating the database are the same. To drop your existing database use (on Microsoft Windows) , terminate all Worklight applications and services, then Start > Run > db2cwadmin.bat > db2 drop database wladmin. You can then recreate the database with the 32K pagesize.
If you don't want to drop your current database, you can also manually create a 32k pagesize bufferpool with the create bufferpool statement, and then manually create a 32k pagesize tablespace using the create tablespace statement and associating it with the 32k bufferpool. Refer to the online Db2 Knowledge Center for details of those statements. However, the best approach is to drop and recreate the database to avoid potential problems during upgrades of Worklight.
If page size is a problem, you will need to drop the database and recreate with a page file size of at least 32k(this seems to be the acceptable minimum) This is more of a db2 issue rather than a mobilefirst problem.
You can do the following from a db2 console :
db2 => list tablespaces show detail
and look for:
Page size (bytes) = 32768
Hope this helps.
Currently I'm trying to query the Windows Search Service from a SQL Server 2008 R2 instance (also tested on SQL Server 2012) . Windows Search is being exposed as an OLE DB datasource, giving me several options to query the search index. When configuring a new Linked Server in SQL Server, Management Studio gives me the option to select the Microsoft OLE DB Provider for Search, implying that I should be able to connect to it from SQL Server. It turns out to be a challenge to get this up and running however. Below you'll find the error message I stumbled upon.
OLE DB provider "Search.CollatorDSO" for linked server "TESTSERVER" returned message "Command was not prepared.".
Msg 7399, Level 16, State 1, Line 2
The OLE DB provider "Search.CollatorDSO" for linked server "TESTSERVER" reported an error. Command was not prepared.
Msg 7350, Level 16, State 2, Line 2
Cannot get the column information from OLE DB provider "Search.CollatorDSO" for linked server "TESTSERVER".
Things get even more interesting. Although the Linked Server solution isn't working, I'm able to wrap code that queries Windows Search in a CLR Function (using MSDN: Querying the Index Programmatically) and use if successfully within SQL Server. This is however less desirable, because of the steps needed to set it up (deploying the library, configuring permissions, etc.). I've tried several parameter settings, without any luck. I've also tried enabling some of the Search.CollatorDSO provider options, like allowing the provider to be instantiated as an in-process server. I'm currently using the settings below. For security I'm using the login's current security context.
Provider: Microsoft OLE DB Provider for Search
Data source: (local)
Provider string: Provider=Search.CollatorDSO.1;EXTENDED?PROPERTIES="Application=Windows"
Location: -
Additionally I need to search network drives, can this be done using shared Windows libraries?
I'm aware more people have been struggling with this problem over the last few years. I'm wondering if someone has been able to get this up and running, or could point me in the right direction.
OLEDB Works
Normal ADO/OLEDB components can query the Windows Search service with the connection string:
provider=Search.CollatorDSO.1;EXTENDED PROPERTIES="Application=Windows"
And an example query:
SELECT TOP 100000 "System.ItemName",
"System.ItemNameDisplay",
"System.ItemType",
"System.ItemTypeText",
"System.Search.EntryID",
"System.Search.GatherTime",
"System.Search.HitCount",
"System.Search.Store",
"System.ItemUrl",
"System.Filename",
"System.FileExtension",
"System.ItemFolderPathDisplay",
"System.ItemPathDisplay",
"System.DateModified",
"System.ContentType",
"System.ApplicationName",
"System.KindText",
"System.ParsingName",
"System.SFGAOFlags",
"System.Size",
"System.ThumbnailCacheId"
FROM "SystemIndex"
WHERE CONTAINS(*,'"Contoso*"',1033)
You can try the query directly on SQL Server in SQL Server Management Studio by attempting to run:
SELECT *
FROM OPENROWSET(
'Search.CollatorDSO',
'Application=Windows',
'SELECT TOP 100 "System.ItemName", "System.FileName" FROM SystemIndex');
Which gives the errors:
OLE DB provider "Search.CollatorDSO" for linked server "(null)" returned message "Command was not prepared.".
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "Search.CollatorDSO" for linked server "(null)" reported an error. Command was not prepared.
Msg 7350, Level 16, State 2, Line 1
Cannot get the column information from OLE DB provider "Search.CollatorDSO" for linked server "(null)".
Bonus Reading
Connect to Windows Search from SQL Server using Linked Server (January 2011)
Link with SQL Server (May 2008 - December 2012)
Trying to access Windows Search from SQL Server: An Appeal (July 2007)
Calling Windows Search from SQL Server 2008 (March 2011)
OLE DB provider "Search.CollatorDSO" returns "Command was not prepared" (April 2014 - Suggests CLR workaround)
Linked Server to Windows Search (February 2011)
MSDN Blogs: Query to the SYSTEMINDEX to read the Microsoft search results fails when using Search.CollatorDSO provider (August 2009 - suggests CLR workaround)
Vista Search (February 2007)
Have a look at this code..It may help
USE [YourDB]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
Create PROC [dbo].[SearchAllTables]
#SearchStr nvarchar(100)
AS
BEGIN
DECLARE #dml nvarchar(max) = N''
IF OBJECT_ID('tempdb.dbo.#Results') IS NOT NULL DROP TABLE dbo.#Results
CREATE TABLE dbo.#Results
([tablename] nvarchar(100),
[ColumnName] nvarchar(100),
[Value] nvarchar(max))
SELECT #dml += ' SELECT ''' + s.name + '.' + t.name + ''' AS [tablename], ''' +
c.name + ''' AS [ColumnName], CAST(' + QUOTENAME(c.name) +
' AS nvarchar(max)) AS [Value] FROM ' + QUOTENAME(s.name) + '.' + QUOTENAME(t.name) +
' (NOLOCK) WHERE CAST(' + QUOTENAME(c.name) + ' AS nvarchar(max)) LIKE ' + '''%' + #SearchStr + '%'''
FROM sys.schemas s JOIN sys.tables t ON s.schema_id = t.schema_id
JOIN sys.columns c ON t.object_id = c.object_id
JOIN sys.types ty ON c.system_type_id = ty.system_type_id AND c .user_type_id = ty .user_type_id
WHERE t.is_ms_shipped = 0 AND ty.name NOT IN ('timestamp', 'image', 'sql_variant')
INSERT dbo.#Results
EXEC sp_executesql #dml
SELECT *
FROM dbo.#Results
END