Talk:Commit (data management)

This article is rated Stub-class on Wikipedia's content assessment scale.
It is of interest to the following WikiProjects:

Computing

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

Databases (inactive)

This article is within the scope of WikiProject Databases, a project which is currently considered to be inactive.DatabasesWikipedia:WikiProject DatabasesTemplate:WikiProject DatabasesDatabases articles

Text and/or other creative content from this version of Commit (data management) was copied or moved into Commit (revision control) with this edit on 06 June 2015. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists.

Merge

Recommend merging this and other SQL transaction statements into a subsection of Databases article and redirecting these statements there. Comments? SqlPac 05:26, 17 May 2007 (UTC)[reply]

How about...

To quote...

"In this context, a commit with version control systems is not as dangerous as it allows easy rollback, even after the commit has been done."
RDMS or indeed any DMS could have this roll back after a commit, e.g. refund your credit card after you find an iPad is broke etc. Except it is yet another, new, transaction. Unless the RDMS is there to issue death warrents most transactions should have an inverse 81.109.247.189 (talk) 14:14, 20 May 2011 (UTC)[reply]