Tag Info

New answers tagged

6

Multiple ways to get this information: SELECT APP_NAME(); SELECT PROGRAM_NAME(); SELECT [program_name] FROM sys.dm_exec_sessions WHERE session_id = @@SPID; Just keep in mind that it can be spoofed in the connection string or in Management Studio's connection properties. If I connect using the following parameter, all three of the above will return ...


8

Yes, each user will get their own copy of the #temp table, even if they run at the exact same time. (However, don't use global ##temp tables, signified with two leading pound/hash signs.) But why do you need a #temp table here at all? Something like this should work (untested, as I don't have LDAP anywhere near me): CREATE PROCEDURE dbo.stp_adlookup -- ...


1

from a broad sense you'll be just fine doing it this way. Stored procedures have limited scope, so even though (example) 3 users execute the same stored procedure and the temp tables will not co-mingle, they won't even see each other. As long as you don't need to share the results with a different session or a user running a different process Temp table ...


4

You should be just fine, we have countless SPs here that get run 1000s of times a day with temp tables that are named the same and don't have any issues. Here's a visual example. I've created 2 tables on my SQL2014 instance. One was created from SPID 53, the other from SPID 57. Here's what it looks like in Object Explorer: As you can see, though ...


1

To add single quotes in a string literal, just double it, or use the chr function. E.g. 'hello '' world' represents the string hello ' world. 'hello '||char(39)||' world' is the same. '''' is a string literal representing a single single-quote. To get your fixed end time, just concatenate it. select ''''||to_date(:From_date,'dd-mon-yyyy')||'''' from ...


3

Strictly speaking (T-SQL subroutine): No. Technically speaking (a means to abstract formulas to be defined once): Yes. Pragmatically speaking: It depends :). Here are the issues that are currently impeding you regarding restrictions on T-SQL functions: They cannot be declared dynamically They cannot access temporary tables They cannot be aggregate ...


3

No this isn't possible. A permanent TVF or view isn't an option due to the reference to #MyTempTable I've seen a connect item request for temporary views and agree sometimes they would be useful. This was closed as duplicate of one requesting Module-level table expressions. You might be able to rewrite as SELECT A, B, C, CASE ...


0

Join table1 and table2. Something like: SELECT t2.searchItem FROM table2 as t2 JOIN table1 as t1 ON t1.tabid = t2.table2_id WHERE t2.searchItem LIKE CONCAT(sText , '%') AND IFNULL(tabId , '') != '' and t1.table1_id= myId LIMIT 15 ; Bottom line, you don't need the @myCid variable


4

How about simplifying greatly: UPDATE d SET [CreatedDate] = [Source].[t_CreatedDate], [DbDate]= [Source].[t_DbDate], [ModifiedDate] = [Source].[t_ModifiedDate], [SubGUID] = [Source].[t_SubGUID], [eType] = [Source].[t_eType] FROM dbo.NO_table AS d INNER JOIN @track AS [Source] ON d.JobID = [Source].t_JobID WHERE d.[ModifiedDate] < ...


2

Postgres has the serial datatype which matches SQL Server's IDENTITY or MySQL's AUTO_INCREMENT. Internally it is shorthand for a SEQUENCE but does that matter? It acts like IDENTITY/AUTO_INCREMENT: The data types serial and bigserial are not true types, but merely a notational convenience for creating unique identifier columns (similar to the ...


0

The answer is yes ONLY if the files are not in use. USE [master] GO CREATE DATABASE [YourDataBase] ON ( FILENAME = N'Path....\FileName1_Data.MDF' ),-- Data files (mdf/ndf) ( FILENAME = N'Path....\FileName2_log.ldf' ) -- log files (ldf) FOR ATTACH GO


2

You can first check to make sure it actually is a valid MDF file using DBCC CHECKPRIMARYFILE. It is an undocumented command but can be useful at times. If that turns up nothing or shows that it is not a mdf file you can use the RESTORE HEADERONLY to see if it might be a backup file. To your specific question, yes you can attach this as a different database ...


0

The tables need to be normalize first. actualy this answer is not mine. its juergen d who provided me the answer at stackoverflow Add another table. How about: users table -------------- | id | name -------------- | 1 | abc | 2 | def | 3 | ghi cars table -------------------------------- | id | name | description ...


0

The perf problem likely comes from IO that is cached under the week. The weekend work evicts those pages. RAM is ~100x faster than sequential disk IO which again is ~100x faster than random IO. That explains why performance is falling off a cliff. Rewrite your queries so that the working set of touched pages is smaller. This might involve adding indexes. ...


0

Agree that these tables should be normalized, but assuming you can't change the underlying structure: One of the benefits of using a stored procedure is that you don't have to put everything in one SQL statement, so you can piece out the more complicated requests. For this one, one way to do it is to gather the distinct car names first, like (pseudocode): ...


0

Most likely activity on the server over the weekend has caused your data to be evicted from memory. This is just the way life is in a shared environment with limited resources. It would be good to understand what's happening over the weekend and how your usage affect other users of this service. You could schedule a job for early on Monday, before anyone is ...



Top 50 recent answers are included