Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


How to preserve global temporary table data


How to preserve global temporary table data

Author
Message
sharky
sharky
Valued Member
Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)Valued Member (66 reputation)

Group: General Forum Members
Points: 66 Visits: 441
Lynn Pettis (3/29/2013)
SQLRNNR (3/29/2013)
Lynn Pettis (3/29/2013)
ScottPletcher (3/29/2013)
The advantage to tempdb is that there is less overhead writing data there since SQL "knows" it never has to recover tempdb.


Really? Last I heard all updates, deletes, inserts were all still logged to the transaction log and tempdb has a transaction log.

If the data needs to survive an unexpected server restart or crash, say bye bye to ANY data you had written to ANY tables temporary or permanent that exist in tempdb.

Just saying.


I think one way to see this is that tempdb does not need to be backed up. Since you don't recover/backup tempdb, it is less overhead.


You can't backup tempdb, you get the following error:

Msg 3147, Level 16, State 3, Line 1
Backup and restore operations are not allowed on database tempdb.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

I just have a real problem with using tempdb in the manner suggested. And I have a problem with SQL Server "knowing" that since it doesn't have to recover data that there are less resources used when writing data to tables in tempdb. I mean, really?



Although data gets logged in tempdb as well, there is a difference in the way it is logged and the amount of overhead required.

1)Because no recovery is required, only the original data is logged, and not the new values(as in another database). This requires less logging
2) Tempdb does not have to be recovered, and therefore the log records does not have to be flushed synchronously in Tempdb

This is what is meant by "knowing"...
ScottPletcher
ScottPletcher
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3944 Visits: 6680
sharky (3/31/2013)
Lynn Pettis (3/29/2013)
SQLRNNR (3/29/2013)
Lynn Pettis (3/29/2013)
ScottPletcher (3/29/2013)
The advantage to tempdb is that there is less overhead writing data there since SQL "knows" it never has to recover tempdb.


Really? Last I heard all updates, deletes, inserts were all still logged to the transaction log and tempdb has a transaction log.

If the data needs to survive an unexpected server restart or crash, say bye bye to ANY data you had written to ANY tables temporary or permanent that exist in tempdb.

Just saying.


I think one way to see this is that tempdb does not need to be backed up. Since you don't recover/backup tempdb, it is less overhead.


You can't backup tempdb, you get the following error:

Msg 3147, Level 16, State 3, Line 1
Backup and restore operations are not allowed on database tempdb.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

I just have a real problem with using tempdb in the manner suggested. And I have a problem with SQL Server "knowing" that since it doesn't have to recover data that there are less resources used when writing data to tables in tempdb. I mean, really?



Although data gets logged in tempdb as well, there is a difference in the way it is logged and the amount of overhead required.

1)Because no recovery is required, only the original data is logged, and not the new values(as in another database). This requires less logging
2) Tempdb does not have to be recovered, and therefore the log records does not have to be flushed synchronously in Tempdb

This is what is meant by "knowing"...



Yes, really. SQL can take certain shortcuts when logging data for tempdb, "knowing" that a forward recovery will never be required.

Of course there are at least a dozen ways to use a non-tempdb table to do it, but all of them will intrinsically have at least slightly more overhead, and more if the non-tempdb db is in full recovery vs simple, as user dbs tend to be.

SQL DBA,SQL Server MVP('07, '08, '09)

Prosecutor James Blackburn, in closing argument in the "Fatal Vision" murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."
rajarshi_ghosh_05
rajarshi_ghosh_05
Grasshopper
Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)

Group: General Forum Members
Points: 10 Visits: 30
Guys, No luck. DBAs are not going to give me the permission to create table in tempdb so I come up with an idea to put both updlock and holdlock (outside the transaction) on the global temp table. However sometime it works and sometime it not. I dont understand about this strange behavior!! Maybe i need more testing on this. Will keep you posted.
DiverKas
DiverKas
SSC Veteran
SSC Veteran (253 reputation)SSC Veteran (253 reputation)SSC Veteran (253 reputation)SSC Veteran (253 reputation)SSC Veteran (253 reputation)SSC Veteran (253 reputation)SSC Veteran (253 reputation)SSC Veteran (253 reputation)

Group: General Forum Members
Points: 253 Visits: 460
rajarshi_ghosh_05 (4/2/2013)
Guys, No luck. DBAs are not going to give me the permission to create table in tempdb so I come up with an idea to put both updlock and holdlock (outside the transaction) on the global temp table. However sometime it works and sometime it not. I dont understand about this strange behavior!! Maybe i need more testing on this. Will keep you posted.


Why are you resisting a permanent table in a user DB? Datetimestamp it and put an ID on it so the user can grab "their" messages, and an agent job to purge anything older than 121 minutes. Easy to do, without doing lock gyrations that arent recommended anyway.

Dont make this harder than it is.
rajarshi_ghosh_05
rajarshi_ghosh_05
Grasshopper
Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)

Group: General Forum Members
Points: 10 Visits: 30
DiverKas (4/2/2013)
rajarshi_ghosh_05 (4/2/2013)
Guys, No luck. DBAs are not going to give me the permission to create table in tempdb so I come up with an idea to put both updlock and holdlock (outside the transaction) on the global temp table. However sometime it works and sometime it not. I dont understand about this strange behavior!! Maybe i need more testing on this. Will keep you posted.


Why are you resisting a permanent table in a user DB? Datetimestamp it and put an ID on it so the user can grab "their" messages, and an agent job to purge anything older than 121 minutes. Easy to do, without doing lock gyrations that arent recommended anyway.

Dont make this harder than it is.


Actually all the people who are architect of this database are from Oracle background (me as well). Without knowing the limitation of sql server temp table the database design was made and approved by client. Now if we want to create any new table that needs to be passed through lot of process which we want to prevent and that is the reason for so much complexity.
Lynn Pettis
Lynn Pettis
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24198 Visits: 37964
rajarshi_ghosh_05 (4/2/2013)
DiverKas (4/2/2013)
rajarshi_ghosh_05 (4/2/2013)
Guys, No luck. DBAs are not going to give me the permission to create table in tempdb so I come up with an idea to put both updlock and holdlock (outside the transaction) on the global temp table. However sometime it works and sometime it not. I dont understand about this strange behavior!! Maybe i need more testing on this. Will keep you posted.


Why are you resisting a permanent table in a user DB? Datetimestamp it and put an ID on it so the user can grab "their" messages, and an agent job to purge anything older than 121 minutes. Easy to do, without doing lock gyrations that arent recommended anyway.

Dont make this harder than it is.


Actually all the people who are architect of this database are from Oracle background (me as well). Without knowing the limitation of sql server temp table the database design was made and approved by client. Now if we want to create any new table that needs to be passed through lot of process which we want to prevent and that is the reason for so much complexity.


If it is to support a process inherent in the design of the database, then it should be included in the database.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Lynn Pettis
Lynn Pettis
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24198 Visits: 37964
ScottPletcher (4/1/2013)
sharky (3/31/2013)
Lynn Pettis (3/29/2013)
SQLRNNR (3/29/2013)
Lynn Pettis (3/29/2013)
ScottPletcher (3/29/2013)
The advantage to tempdb is that there is less overhead writing data there since SQL "knows" it never has to recover tempdb.


Really? Last I heard all updates, deletes, inserts were all still logged to the transaction log and tempdb has a transaction log.

If the data needs to survive an unexpected server restart or crash, say bye bye to ANY data you had written to ANY tables temporary or permanent that exist in tempdb.

Just saying.


I think one way to see this is that tempdb does not need to be backed up. Since you don't recover/backup tempdb, it is less overhead.


You can't backup tempdb, you get the following error:

Msg 3147, Level 16, State 3, Line 1
Backup and restore operations are not allowed on database tempdb.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

I just have a real problem with using tempdb in the manner suggested. And I have a problem with SQL Server "knowing" that since it doesn't have to recover data that there are less resources used when writing data to tables in tempdb. I mean, really?



Although data gets logged in tempdb as well, there is a difference in the way it is logged and the amount of overhead required.

1)Because no recovery is required, only the original data is logged, and not the new values(as in another database). This requires less logging
2) Tempdb does not have to be recovered, and therefore the log records does not have to be flushed synchronously in Tempdb

This is what is meant by "knowing"...



Yes, really. SQL can take certain shortcuts when logging data for tempdb, "knowing" that a forward recovery will never be required.

Of course there are at least a dozen ways to use a non-tempdb table to do it, but all of them will intrinsically have at least slightly more overhead, and more if the non-tempdb db is in full recovery vs simple, as user dbs tend to be.


First of all, I am still going to express my concern of SQL Server "Knowing" that certain things can or can't be done. This implies intelligence in the code itself, not conscious decisions made by developers when designing and implementing the code. Implementing enhancements and optimizations is not the same thing as a piece of software "knowing" something.

On to some interesting things. I have already been able to do a little playing with permanent tables in both a user database and in tempdb. I have found the that there are minor differences in transaction logging between the two. With the simplistic testing I have been able to do so far, I really don't think it is enough to justify using tempdb in the manor suggested by the OP or Scott.

I do firmly believe that if the process being developed is meant to support a business process inherent in the application that the database tables needed to support that process belong in the database itself. It is a waste of time and effort to attempt to bypass change control just because it is a difficult process. If the customer/client wants a specific behavior in the application and it requires changes to the database (the addition of tables in this case), then show them this and explain it. If they want that behavior they should then approve the changes necessary to support it. The other choice is to go without the behavior.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
ScottPletcher
ScottPletcher
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3944 Visits: 6680
Lynn Pettis (4/4/2013)
ScottPletcher (4/1/2013)
sharky (3/31/2013)
Lynn Pettis (3/29/2013)
SQLRNNR (3/29/2013)
Lynn Pettis (3/29/2013)
ScottPletcher (3/29/2013)
The advantage to tempdb is that there is less overhead writing data there since SQL "knows" it never has to recover tempdb.


Really? Last I heard all updates, deletes, inserts were all still logged to the transaction log and tempdb has a transaction log.

If the data needs to survive an unexpected server restart or crash, say bye bye to ANY data you had written to ANY tables temporary or permanent that exist in tempdb.

Just saying.


I think one way to see this is that tempdb does not need to be backed up. Since you don't recover/backup tempdb, it is less overhead.


You can't backup tempdb, you get the following error:

Msg 3147, Level 16, State 3, Line 1
Backup and restore operations are not allowed on database tempdb.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

I just have a real problem with using tempdb in the manner suggested. And I have a problem with SQL Server "knowing" that since it doesn't have to recover data that there are less resources used when writing data to tables in tempdb. I mean, really?



Although data gets logged in tempdb as well, there is a difference in the way it is logged and the amount of overhead required.

1)Because no recovery is required, only the original data is logged, and not the new values(as in another database). This requires less logging
2) Tempdb does not have to be recovered, and therefore the log records does not have to be flushed synchronously in Tempdb

This is what is meant by "knowing"...



Yes, really. SQL can take certain shortcuts when logging data for tempdb, "knowing" that a forward recovery will never be required.

Of course there are at least a dozen ways to use a non-tempdb table to do it, but all of them will intrinsically have at least slightly more overhead, and more if the non-tempdb db is in full recovery vs simple, as user dbs tend to be.


First of all, I am still going to express my concern of SQL Server "Knowing" that certain things can or can't be done. This implies intelligence in the code itself, not conscious decisions made by developers when designing and implementing the code. Implementing enhancements and optimizations is not the same thing as a piece of software "knowing" something.

On to some interesting things. I have already been able to do a little playing with permanent tables in both a user database and in tempdb. I have found the that there are minor differences in transaction logging between the two. With the simplistic testing I have been able to do so far, I really don't think it is enough to justify using tempdb in the manor suggested by the OP or Scott.

I do firmly believe that if the process being developed is meant to support a business process inherent in the application that the database tables needed to support that process belong in the database itself. It is a waste of time and effort to attempt to bypass change control just because it is a difficult process. If the customer/client wants a specific behavior in the application and it requires changes to the database (the addition of tables in this case), then show them this and explain it. If they want that behavior they should then approve the changes necessary to support it. The other choice is to go without the behavior.



C'mon, that's why I put "knowing" in quotes: to clearly indicate that it's not intended to be taken literally ( even by the perpetually pedantic ;-)).

Hmm, by that latter reasoning, temp tables themselves should not be used then? And all work space used in db processing should be in that db?!

SQL DBA,SQL Server MVP('07, '08, '09)

Prosecutor James Blackburn, in closing argument in the "Fatal Vision" murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."
Lynn Pettis
Lynn Pettis
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24198 Visits: 37964
ScottPletcher (4/4/2013)
Lynn Pettis (4/4/2013)
ScottPletcher (4/1/2013)
sharky (3/31/2013)
Lynn Pettis (3/29/2013)
SQLRNNR (3/29/2013)
Lynn Pettis (3/29/2013)
ScottPletcher (3/29/2013)
The advantage to tempdb is that there is less overhead writing data there since SQL "knows" it never has to recover tempdb.


Really? Last I heard all updates, deletes, inserts were all still logged to the transaction log and tempdb has a transaction log.

If the data needs to survive an unexpected server restart or crash, say bye bye to ANY data you had written to ANY tables temporary or permanent that exist in tempdb.

Just saying.


I think one way to see this is that tempdb does not need to be backed up. Since you don't recover/backup tempdb, it is less overhead.


You can't backup tempdb, you get the following error:

Msg 3147, Level 16, State 3, Line 1
Backup and restore operations are not allowed on database tempdb.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

I just have a real problem with using tempdb in the manner suggested. And I have a problem with SQL Server "knowing" that since it doesn't have to recover data that there are less resources used when writing data to tables in tempdb. I mean, really?



Although data gets logged in tempdb as well, there is a difference in the way it is logged and the amount of overhead required.

1)Because no recovery is required, only the original data is logged, and not the new values(as in another database). This requires less logging
2) Tempdb does not have to be recovered, and therefore the log records does not have to be flushed synchronously in Tempdb

This is what is meant by "knowing"...



Yes, really. SQL can take certain shortcuts when logging data for tempdb, "knowing" that a forward recovery will never be required.

Of course there are at least a dozen ways to use a non-tempdb table to do it, but all of them will intrinsically have at least slightly more overhead, and more if the non-tempdb db is in full recovery vs simple, as user dbs tend to be.


First of all, I am still going to express my concern of SQL Server "Knowing" that certain things can or can't be done. This implies intelligence in the code itself, not conscious decisions made by developers when designing and implementing the code. Implementing enhancements and optimizations is not the same thing as a piece of software "knowing" something.

On to some interesting things. I have already been able to do a little playing with permanent tables in both a user database and in tempdb. I have found the that there are minor differences in transaction logging between the two. With the simplistic testing I have been able to do so far, I really don't think it is enough to justify using tempdb in the manor suggested by the OP or Scott.

I do firmly believe that if the process being developed is meant to support a business process inherent in the application that the database tables needed to support that process belong in the database itself. It is a waste of time and effort to attempt to bypass change control just because it is a difficult process. If the customer/client wants a specific behavior in the application and it requires changes to the database (the addition of tables in this case), then show them this and explain it. If they want that behavior they should then approve the changes necessary to support it. The other choice is to go without the behavior.



C'mon, that's why I put "knowing" in quotes: to clearly indicate that it's not intended to be taken literally ( even by the perpetually pedantic ;-)).

Hmm, by that latter reasoning, temp tables themselves should not be used then? And all work space used in db processing should be in that db?!


Really, you are going there? And you think I am being perpetually pedantic?

No, I am not advocating NOT using temp tables. I am advocating that temp tables have no business being used to hold temporal data over a period of time to support a business process, especially when that business process hasn't been fully explained. No one has answered the question I put forth earlier. Does the loss of data in that temporary table matter if there is restart fo SQL Server during the time frame in which the data is to be persisted (in this case 120 minutes). If data is written at 9:00 AM and the server restarts at 9:10 AM is there a problem with the loss of data written 10 minutes earlier, or 100 minutes earlier?


Temp tables, table variables, all have a purpose and a time to use them. Use them correctly.

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
rajarshi_ghosh_05
rajarshi_ghosh_05
Grasshopper
Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)Grasshopper (10 reputation)

Group: General Forum Members
Points: 10 Visits: 30
Lynn Pettis (4/4/2013)
ScottPletcher (4/4/2013)
Lynn Pettis (4/4/2013)
ScottPletcher (4/1/2013)
sharky (3/31/2013)
Lynn Pettis (3/29/2013)
SQLRNNR (3/29/2013)
Lynn Pettis (3/29/2013)
ScottPletcher (3/29/2013)
The advantage to tempdb is that there is less overhead writing data there since SQL "knows" it never has to recover tempdb.


Really? Last I heard all updates, deletes, inserts were all still logged to the transaction log and tempdb has a transaction log.

If the data needs to survive an unexpected server restart or crash, say bye bye to ANY data you had written to ANY tables temporary or permanent that exist in tempdb.

Just saying.


I think one way to see this is that tempdb does not need to be backed up. Since you don't recover/backup tempdb, it is less overhead.


You can't backup tempdb, you get the following error:

Msg 3147, Level 16, State 3, Line 1
Backup and restore operations are not allowed on database tempdb.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

I just have a real problem with using tempdb in the manner suggested. And I have a problem with SQL Server "knowing" that since it doesn't have to recover data that there are less resources used when writing data to tables in tempdb. I mean, really?



Although data gets logged in tempdb as well, there is a difference in the way it is logged and the amount of overhead required.

1)Because no recovery is required, only the original data is logged, and not the new values(as in another database). This requires less logging
2) Tempdb does not have to be recovered, and therefore the log records does not have to be flushed synchronously in Tempdb

This is what is meant by "knowing"...



Yes, really. SQL can take certain shortcuts when logging data for tempdb, "knowing" that a forward recovery will never be required.

Of course there are at least a dozen ways to use a non-tempdb table to do it, but all of them will intrinsically have at least slightly more overhead, and more if the non-tempdb db is in full recovery vs simple, as user dbs tend to be.


First of all, I am still going to express my concern of SQL Server "Knowing" that certain things can or can't be done. This implies intelligence in the code itself, not conscious decisions made by developers when designing and implementing the code. Implementing enhancements and optimizations is not the same thing as a piece of software "knowing" something.

On to some interesting things. I have already been able to do a little playing with permanent tables in both a user database and in tempdb. I have found the that there are minor differences in transaction logging between the two. With the simplistic testing I have been able to do so far, I really don't think it is enough to justify using tempdb in the manor suggested by the OP or Scott.

I do firmly believe that if the process being developed is meant to support a business process inherent in the application that the database tables needed to support that process belong in the database itself. It is a waste of time and effort to attempt to bypass change control just because it is a difficult process. If the customer/client wants a specific behavior in the application and it requires changes to the database (the addition of tables in this case), then show them this and explain it. If they want that behavior they should then approve the changes necessary to support it. The other choice is to go without the behavior.



C'mon, that's why I put "knowing" in quotes: to clearly indicate that it's not intended to be taken literally ( even by the perpetually pedantic ;-)).

Hmm, by that latter reasoning, temp tables themselves should not be used then? And all work space used in db processing should be in that db?!


Really, you are going there? And you think I am being perpetually pedantic?

No, I am not advocating NOT using temp tables. I am advocating that temp tables have no business being used to hold temporal data over a period of time to support a business process, especially when that business process hasn't been fully explained. No one has answered the question I put forth earlier. Does the loss of data in that temporary table matter if there is restart fo SQL Server during the time frame in which the data is to be persisted (in this case 120 minutes). If data is written at 9:00 AM and the server restarts at 9:10 AM is there a problem with the loss of data written 10 minutes earlier, or 100 minutes earlier?

Temp tables, table variables, all have a purpose and a time to use them. Use them correctly.


No. We dont bother about the temp table data not if anything happens like network failure or server restart or user system restart! We dont have to preserve that data. Only thing if nothing happens then we need to keep the data till 120 min; because user can download the data in excel at anytime between this.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search