1. SQL Server temporary tables Old Blue Notes: Introduction: Temporary data tables are often stored. The client can use the clientdataset memory table of Delphi. However, clientdataset is similar to a table and does not support the SQL language. You can also use temporary tables. Sometimes we do not need to worry about the life cycle of a temporary table, but use the actual table for temporary use. Tell us what tempxxx is like. They are temporary tables. There is no problem with creating and releasing. So what is the period of a temporary table? Is there any special usage? 1. The difference between a global temporary table and a temporary table: The field of view is different. A global temporary table is of course a table with # headers. A common temporary table is # headers. Their cycle should be born with the birth of a connection, that is, the connection, and die with the disconnection of the connection. The difference is that the field of view is different. Global table, all authorized connections can be seen. However, only the connection created for the common temporary table (local temporary table) can be seen. In particular, each connection of isql.exe in SQL Server is a connection. For example, if an application app.exe connects to SQL Server data only through adoconnection, the corresponding table created by the adoqueryworkflow in this connection can be used by another app.exeits appx.exe. Others or others cannot be seen. Trap: if an application app.exe has a stored procedure connected to the same adoconnection as tadoquery, remember to use the temporary table created by the Stored Procedure (not global) and cannot be accessed by tadoquery under the connection. The reason is that the stored procedure itself is executed on the server and should be the connection of the server. 2. Store and create a global or temporary table. We all know that temporary tables or Global tables are stored in SQL Server's tempdb database. We use them when accessing tables #, however, in the process, user tables in tempdb are stored in the format of # XXX _________ processing identifier XXX (whether the user table is a process ID is unknown or not ). You can see them through the tempdb of isql.exe. 3. Headache initialization table Initialize the table, why is it a headache? After all, use drop or something. Or it is difficult to judge. In fact, it is also very simple. In addition, creating temporary tables is boring SQL statements. How can this problem be solved. Method 1: Use the stored procedure. You can directly write SQL statements or exec (@ v_ SQL ). Method 2: Save the temporary table to memo in the data, read the table, and execute it directly. Method 1: Common exists functions can be used. For example: if exists (select * From tempdb .. sysobjects where id = object_id (@ stmpwarea) and type = "U ") Method 2: If object_id ('tempdb. DBO. # '+ @ v_userid) is null Method 1: (thanks to Aman, confused) A statistical temporary table that uses tadoproc to execute the stored procedure, as follows: Create procedure initcreatecoawardtable Begin If not (object_id ('tempdb. DBO. # tmp_detail ') is null) Drop table tempdb. DBO. # tmp_detail Create Table tempdb. DBO. # tmp_detail ( [ID] [int] identity (1, 1) not null, [Document category] [varchar] (20) Collate chinese_prc_ci_as null, [Document No.] [varchar] (20) Collate chinese_prc_ci_as null, (.. All the complexity here can be ..... Omitted ...) Select * From tempdb. DBO. # tmp_detail End Go Run the stored procedure using tadoproc on the client, With sproc do Begin Try Close; Procedurename: = spname; Parameters. Refresh; Prepared; Execproc; Open; // This statement cannot be omitted. If the database name is ignored, the object in tempdb will be referenced. Except Close; Exit; End; Result: = true; End; In this way, your tadoproc can use the append and insert statements at will. It is better that you do not need to clear the statements, and the method is flexible. It is a bit more effective in processing concurrency. Of course, some people are still using the actual table to replace it, and you have to recycle it when using sessions to solve the problem. Very troublesome. And the flexibility is much lower. The following is an example of an application reprinted: Use the global temporary table of SQL Server to prevent repeated logins When developing business software, we often encounter the following problem: how to prevent users from repeatedly logging on to our system? Especially for banks or financial departments, it is necessary to restrict users to log on multiple times as their employee IDs. Some people may say that they should add a field in the user information table to determine the logon status of the user's employee ID, write 1 after logon, write 0 when exiting, and determine whether the flag is 1 when logon, if yes, the user's employee ID is not allowed to log on. However, this will inevitably lead to new problems: in the case of unpredictable phenomena such as power outages, the system exits abnormally and cannot set the mark position to 0, so next time you log on with this user's employee ID, you cannot log on. What should I do? Maybe we can change our thinking: What can be automatically recycled by the system after the connection is disconnected? By the way, SQL Server temporary tables have this feature! However, in this case, we cannot use a local temporary table. Because a local temporary table is an independent object for each connection, we can only use a global temporary table for our purpose. Now, the situation is clear. We can write a simple stored procedure like the following: Create procedure gp_findtemptable -- 2001/10/26 21:36 zhuzhichao in Nanjing /* Search for a global temporary table named after the operator's employee ID * If not, set the out parameter to 0 and create the table. If yes, set the out parameter to 1. * After the connection is disconnected, the global temporary table is automatically reclaimed by SQL Server. * In the event of an accident such as power failure, although the global temporary table still exists in tempdb, it is no longer active. * When the object_id function is used to determine whether the object does not exist, it is considered as nonexistent .*/ @ V_userid varchar (6), -- operator ID @ I _out int out -- output parameter 0: No Logon; 1: logged on As Declare @ v_ SQL varchar (100) If object_id ('tempdb. DBO. # '+ @ v_userid) is null Begin Set @ v_ SQL = 'create table # '+ @ v_userid +' (userid varchar (6 ))' Exec (@ v_ SQL) Set @ I _out = 0 End Else Set @ I _out = 1 In this process, we can see that if the global temporary table named after the user's employee number does not exist, a new table will be created and the out parameter is set to 0, if it already exists, set the out parameter to 1. In this way, when we call this process in our application, if the out parameter obtained is 1, we can jump out of a message and tell the user to say "sorry, this employee ID is in use!" Sample judgment method: Select @ stmpwarea = "tempdb .. [# marwarea" + @ computername + "]" If exists (select * From tempdb .. sysobjects where id = object_id (@ stmpwarea) and type = "U ") Begin Set @ stmpwarea = "[# marwarea" + @ computername + "]" Exec ("Drop table" + @ stmpwarea) End Else Set @ stmpwarea = "[# marwarea" + @ computername + "]" |