Activity overview
Latest activity by dhtucker
Still a problem with the latest SQL Toolbelt installer / comments
Still a problem with the latest SQL Toolbelt installer
SQL Prompt 10.12.5.30313, SSMS 18.12.1, Win 10 v 20H2 Opened SSMS, opened Tab History, waited 60sec - no response Switched from Starred tab to All, waited 60sec - no response Resized Tab History window, waited 60sec - no response Switched from All tab to Closed, waited 60 sec - no response Maximized Tab History window, waited 60 sec - no response Uninstalled 10.12.5.30313, reinstalled 10.12.4.29949 (Thanks @ostandage for the download link!) Tab history restored - the uninstall graciously didn't delete %localappdata%\Red Gate\SQL Prompt 10 so I needn't have bothered to copy it elsewhere first. Having gone a day and a half without access to all the stuff I've trusted Tab History to store for me, I'm now concerned about:
What's the best way to capture a "backup" of \SQL Prompt 10, short of navigating there directly and making my own directory copy (i.e. does SQL Prompt make its own failsafe copy somewhere)?
How can I extract the contents of SavedTabs.db since SQL Prompt doesn't have an export/import option?
/ comments
SQL Prompt 10.12.5.30313, SSMS 18.12.1, Win 10 v 20H2Opened SSMS, opened Tab History, waited 60sec - no responseSwitched from Starred tab to All, waited 60sec - no responseResized Tab History windo...
Just tried this again using v7.2.4.11418, error remains unresolved. In response to "git status" I see: $ git status On branch master Your branch is up to date with 'origin/master'. Untracked files: (use "git add <file>..." to include in what will be committed) develop/ master/ rc/ nothing added to commit but untracked files present (use "git add" to track)
It's mistaking untracked files for pending changes. / comments
Just tried this again using v7.2.4.11418, error remains unresolved. In response to "git status" I see:$ git statusOn branch masterYour branch is up to date with 'origin/master'.Untracked files: (...
Same complaint (v7.1.12.10363) In response to "git status" I see: On branch master Your branch is up to date with 'origin/master' Untracked files: (use "git add <file>..." to include in what will be committed) develop/ rc/ master/ nothing added to commit but untracked files present (use "git add" to track) My primary scripts directory (being referenced above) is: C:\Users\dtucker\Documents\Schema.RSMS SourceTree populates this folder with whatever I've selected as my current branch. ALSO contained in this folder are three subfolders, which allow me to pull representations of 'develop', 'rc', and 'master' branches for comparison, and for use by SSC-linked databases representing each of those branches. So yes, my scripts folder contains untracked files (folders, actually) which I don't want tracked. Is SSC mistaking these for "pending changes"? / comments
Same complaint (v7.1.12.10363) In response to "git status" I see:On branch masterYour branch is up to date with 'origin/master'Untracked files: (use "git add <file>..." to include in what will be ...
I'm experiencing the same problem, and I confirmed that both the source and target databases are of collation: SQL_Latin1_General_CP1_CI_AS / comments
I'm experiencing the same problem, and I confirmed that both the source and target databases are of collation: SQL_Latin1_General_CP1_CI_AS
I did not drop _ynz_tx1 prior to running the restore - the intent is to overlay the test database _ynz_tx1 with the contents of the production database YNZ_TX1.
The restore is not attempting to overwrite the files belonging to _ynz_tx1 (the target, test database) as one would expect it to do. Instead, according to SQL error 1834, it's complaining about being unable to overwrite the file \FTData\LibraryFullTextCatalog0043 because it's in use by YNZ_TX1 (the production database from which the backup file was generated). / comments
I did not drop _ynz_tx1 prior to running the restore - the intent is to overlay the test database _ynz_tx1 with the contents of the production database YNZ_TX1.
The restore is not attempting to ove...
For database backups NOT containing full-text catalogs, the first RESTORE syntax works without requiring explicit MOVE statements:
-sql "RESTORE DATABASE _ynz_tx1 FROM DISK=[\\nas-sql\wilcomp_sql\temporary\YNZ_TX1_205042.sqb] WITH RECOVERY, REPLACE, DISCONNECT_EXISTING, SINGLERESULTSET" '
This form is able to link the logical names from the backup to the phyical paths of the target database and overwrite the contents of the target without needing explicit MOVE statements. What's different about full-text catalogs? / comments
For database backups NOT containing full-text catalogs, the first RESTORE syntax works without requiring explicit MOVE statements:
-sql "RESTORE DATABASE _ynz_tx1 FROM DISK=[\\nas-sql\wilcomp_sql\t...
RG RESTORE FILELISTONLY resultset doesn't match SQL native
According to MSDN, the resultset from RESTORE FILELISTONLY should be:
declare @fileListTable table(
LogicalName nvarchar(128),
PhysicalName nvarchar(260),
[Type] ...
errors 1834, 3013, 3119, 3156 restore backup w/ full-text
DECLARE @exitCode INT
DECLARE @sqlErrorCode INT
DECLARE @strSql NVARCHAR(1000)
SET @strSql = '
-sql "RESTORE DATABASE _ynz_tx1 FROM DISK=[\\nas-sql\wilcomp_sql\temporary\YNZ_TX1_205042.sqb] WITH RE...