لتطبيق ما ذكر سابقاً عدنا جدولين كما في الصورة أدناه
الأول أسمه Customers و يتكون من مجموعة من ال columns التالية:
1.CustomerID
2.CustomerName
3.ContactName
4.Address
5.City
6.PostalCode
7.Country
و الجدول الثاني أسمه Suppliers و يتكون من الأعمدة التالية:
1.SupplierID
2.SupplierName
3.ContactName
4.Address
5.City
6.PostalCode
7.Country
8.Phone
الأول أسمه Customers و يتكون من مجموعة من ال columns التالية:
1.CustomerID
2.CustomerName
3.ContactName
4.Address
5.City
6.PostalCode
7.Country
و الجدول الثاني أسمه Suppliers و يتكون من الأعمدة التالية:
1.SupplierID
2.SupplierName
3.ContactName
4.Address
5.City
6.PostalCode
7.Country
8.Phone
المثال الأول: تمليء كل أعمدة جدول ال Customers لكن هنا منكدر نستخدم طريقة ال * الي وضحت سابقا ( لأن عمود ال phone موجود بجدول ال suppliers و غير موجود بجدول ال Customers ) لذلك أستخدمنا هذه الطريقه.
المثال الثاني: أخذنا فقط بيانات لثلاث Columns من جدول ال suppliers و ضفناها لجدول ال Customers.
المثال الثالث: نفس الطريقة الثانيه لكن أستخدام ال condition (where) لأضافة المجهزين الألمان فقط.
المثال الثاني: أخذنا فقط بيانات لثلاث Columns من جدول ال suppliers و ضفناها لجدول ال Customers.
المثال الثالث: نفس الطريقة الثانيه لكن أستخدام ال condition (where) لأضافة المجهزين الألمان فقط.
2. Update Statement
ال Update statement تمكننا من التعديل على بيانات موجودة في table معين. و التعديل يكون على بيانات سجل record/row واحد أو على مجموعة من records و أيضا على عمود column واحد أو مجموعة من columns.
ال Syntax العام ل Update Statement موضح في الصورة أدناه.
ال Update statement تمكننا من التعديل على بيانات موجودة في table معين. و التعديل يكون على بيانات سجل record/row واحد أو على مجموعة من records و أيضا على عمود column واحد أو مجموعة من columns.
ال Syntax العام ل Update Statement موضح في الصورة أدناه.
مثلا نرجع لجدول ال Customers اذا نريد نغير أسم و مدينة أول customer بال table فنستخدم ال Update Statement كما في الصورة أعلاه.
Note:
طبعاً بما أنهُ نريد نغير بعض المعلومات عن الزبون الأول أذن في الشرط نستخدم الشي الي يُعرَف/يُميز الزبون على أنه زبون رقم 1 و هو ال
Primary key (CustomerID)
طبعاً في حال كتبنا في شرط ال where
CustomerName='Alfreds Futterkiste'
الي رح يصير: وين ميشوف أسم Alfreds Futterkiste بالجدول رح يغيره الى Farid Laftaa و يغير المدينة city أيضا.. لذلك الأفضل نستخدم الشي الي يميز الزبون من غيره و هو CustomerID.
Note:
طبعاً بما أنهُ نريد نغير بعض المعلومات عن الزبون الأول أذن في الشرط نستخدم الشي الي يُعرَف/يُميز الزبون على أنه زبون رقم 1 و هو ال
Primary key (CustomerID)
طبعاً في حال كتبنا في شرط ال where
CustomerName='Alfreds Futterkiste'
الي رح يصير: وين ميشوف أسم Alfreds Futterkiste بالجدول رح يغيره الى Farid Laftaa و يغير المدينة city أيضا.. لذلك الأفضل نستخدم الشي الي يميز الزبون من غيره و هو CustomerID.
ممكن نطبق آخر الأمثلة عن Insert Into Select Statement و Update Statement بهذا الرابط
https://www.w3schools.com/sql/trysql.asp?filename=trysql_insert_into_select
https://www.w3schools.com/sql/trysql.asp?filename=trysql_insert_into_select
3. Delete Statement
ال Delete statement تمكننا من حذف بيانات record واحد أو أكثر من Table معين.
ال Syntax العام ل Delete Statement موضح في الصورة أدناه.
ال Delete statement تمكننا من حذف بيانات record واحد أو أكثر من Table معين.
ال Syntax العام ل Delete Statement موضح في الصورة أدناه.
Note:
في حال أدرنا نحذف record من table معين و كان هذا ال record يحتوي على column يكون primary key و يستخدم للربط مع جدول آخر فهنا مانكدر نحذف هذا ال record انما بالبداية نحذف كل ال records من الجداول الأخرى المرتبطه بهذا الجدول بعدها بأمكانه نحذف هذا ال record..
مثال:
مثل ما عرفنا سابقا أن HR Schema تتضمن مجموعة من الجداول منها جدول Employees and Departments. طبعاً جدول ال employees يرتبط مع جدول ال Departments عن طريق عمود Department_ID و الي هو Foreign key بجدول ال Employees و Primary key بجدول Departments.
فاذا أردنا نعمل delete لأداره من أدارات جدول ال Departments يعني نحذف record فهنا مرح يسمحلنا النظام, أنما يطلب منا أولا نحذف كل الrecords من الجداول الأخرى المرتبطة بهذا الجدول (يعني مثلا نمسح كل الموظفين employees بجدول الموظفين الي ينتمون لهذه الأدارة) ثم نمسح هذه الأدارة من جدول ال Departments...
و هنا تبين قوة ال RDBMS.
في حال أدرنا نحذف record من table معين و كان هذا ال record يحتوي على column يكون primary key و يستخدم للربط مع جدول آخر فهنا مانكدر نحذف هذا ال record انما بالبداية نحذف كل ال records من الجداول الأخرى المرتبطه بهذا الجدول بعدها بأمكانه نحذف هذا ال record..
مثال:
مثل ما عرفنا سابقا أن HR Schema تتضمن مجموعة من الجداول منها جدول Employees and Departments. طبعاً جدول ال employees يرتبط مع جدول ال Departments عن طريق عمود Department_ID و الي هو Foreign key بجدول ال Employees و Primary key بجدول Departments.
فاذا أردنا نعمل delete لأداره من أدارات جدول ال Departments يعني نحذف record فهنا مرح يسمحلنا النظام, أنما يطلب منا أولا نحذف كل الrecords من الجداول الأخرى المرتبطة بهذا الجدول (يعني مثلا نمسح كل الموظفين employees بجدول الموظفين الي ينتمون لهذه الأدارة) ثم نمسح هذه الأدارة من جدول ال Departments...
و هنا تبين قوة ال RDBMS.
Transaction Control Statement (TCS)
اليوم موضوعنا عن Transaction Control Statement
لكن قبل لا نشرح عنها شي خلونا نرجع لما درسناه سابقا. فاذا تذكرون سابقاً ذكرنا ان ال SQL Statement ممكن تكون DML,DDL,TCS, DCL, and SCS. فاحنه سابقا شرحنا عن ال DML statements و اليوم نشرح TCS و بالقادم ان شاء الله نشرح البقية. المهم من شرحنا DML statements مثل ال insert, delete, and update و وضحنا طريقة تطبيق كل وحده منهم (و ممكن في بيئة ال Oracle SQL Developer نكتب DML Sql Statement واحدة او أكثر ). المهم في كل الأحوال توجد شغلة جدا مهمه أنو التغييرات الي تحدث على الجدول عند استخدام هذه ال DML Statements (سواء كانت DML Statement واحدة أو اكثر) لا تحفظ بصورة نهائية في الجدول و لحفظها بصورة نهائية يجب استخدام امر ال Commit بعدها. ال Commit هو أحد Transaction Controls يعني بدون ال commit التغييرات تحفظ بصورة شكلية ) فقط آني اشوفها اي شخص آخر يستخدم نفس هذه ال database مرح يكدر يشوفها.
فال transaction in database هي عبارة عن وحدة عمل منطقيه logical unit of work تتضمن بداخلها على Sql Statement واحدة أو أكثر (و في حال كانت تتضمن على أكثر من sql statements هنا هذه العبارات قد تكون مجموعة من العمليات المنفصلة أو مجموعة من العمليات التي تنفذ كحزمة واحدة أما أن تنجح كلها أو تفشل كلها دفعة واحدة). رح ناخذ examples توضح هذا الكلام.
أذن لإدارة ال transactions نستخدم مجموعة من ال controls تكون كالتالي:
1. Commit
2. RollBack
3. Savepoint
اليوم موضوعنا عن Transaction Control Statement
لكن قبل لا نشرح عنها شي خلونا نرجع لما درسناه سابقا. فاذا تذكرون سابقاً ذكرنا ان ال SQL Statement ممكن تكون DML,DDL,TCS, DCL, and SCS. فاحنه سابقا شرحنا عن ال DML statements و اليوم نشرح TCS و بالقادم ان شاء الله نشرح البقية. المهم من شرحنا DML statements مثل ال insert, delete, and update و وضحنا طريقة تطبيق كل وحده منهم (و ممكن في بيئة ال Oracle SQL Developer نكتب DML Sql Statement واحدة او أكثر ). المهم في كل الأحوال توجد شغلة جدا مهمه أنو التغييرات الي تحدث على الجدول عند استخدام هذه ال DML Statements (سواء كانت DML Statement واحدة أو اكثر) لا تحفظ بصورة نهائية في الجدول و لحفظها بصورة نهائية يجب استخدام امر ال Commit بعدها. ال Commit هو أحد Transaction Controls يعني بدون ال commit التغييرات تحفظ بصورة شكلية ) فقط آني اشوفها اي شخص آخر يستخدم نفس هذه ال database مرح يكدر يشوفها.
فال transaction in database هي عبارة عن وحدة عمل منطقيه logical unit of work تتضمن بداخلها على Sql Statement واحدة أو أكثر (و في حال كانت تتضمن على أكثر من sql statements هنا هذه العبارات قد تكون مجموعة من العمليات المنفصلة أو مجموعة من العمليات التي تنفذ كحزمة واحدة أما أن تنجح كلها أو تفشل كلها دفعة واحدة). رح ناخذ examples توضح هذا الكلام.
أذن لإدارة ال transactions نستخدم مجموعة من ال controls تكون كالتالي:
1. Commit
2. RollBack
3. Savepoint
1.Commit
هذا ال command يستخدم لتثبيت/حفظ التغييرات (البيانات) على الجدول بصورة نهائية.
في لمثال أعلاه استخدمنا two insert statement, فلو افترضنا يوجد user آخر يعمل معي ع هذه ال database فهنا مرح يشوف التغييرات الي ضفتها لل table الا عندما اعمله commit. لان مثل مذكرنا سابقاً التغييرات تحفظ بصورة نهائية عند استخدام الامر commit.
هذا ال command يستخدم لتثبيت/حفظ التغييرات (البيانات) على الجدول بصورة نهائية.
في لمثال أعلاه استخدمنا two insert statement, فلو افترضنا يوجد user آخر يعمل معي ع هذه ال database فهنا مرح يشوف التغييرات الي ضفتها لل table الا عندما اعمله commit. لان مثل مذكرنا سابقاً التغييرات تحفظ بصورة نهائية عند استخدام الامر commit.
خلي نأخذ مثال من الواقع
مثلا موضوع التسوق shopping اونلاين (أي عبر موقع تسوق الكتروني ) ، حاليا توجد العديد من تطبيقات التسوق عبر الانترنيت منها amazone، alibaba و غيرها من التطبيقات. المهم هذه التطبيقات تسمحلك شراء منتج معين اونلاين و الدفع يكون عن طريق البطاقة الائتمانية.
وهذه ال Apps تستخدم Database, وهذا نظام Database يتعاملون معاه فئتين من الناس.
الأولى هم:adminstrators/users أشخاص يتعاملون مع ال database المرتبطة بال application و يقومون بمجموعة من المهام مثلا أضافة منتجات products او التعديل عليها او حذف منتجات موجودة.
و الفئة الثاني: customers/clients أشخاص تتعامل مع ال application المرتبطة بdatabase لتستعرض المنتجات المخزونة بال database لغرض التصفح و شرائها.
فكـ administrator لل database قررت أضافة منتج جديد و عدلت ع سعر او حجم أوقد يكون لون منتج موجود ( يعني أستخدم Insert and Update commands) فخلال الفترة الي اقوم بيها بتنفيذ sql statements الي تقوم بهذا العمل أي شخص client يقوم بأستعراض هذه المنتجات عن طريق ال application رح يشوف النتائج و القيم قبل التغييرات الي قمت بيها لان التغيرات الي صارت هي تغيرات شكليه (فقط آني اشوفها) وليست فعلية (يعني مو الكل يشوفها). طيب لعد متى رح يشوفون التغييرات الي قمت بيها؟ يشوفوها من أكتب و أنفذ الأمر Commit بعد أوامر ال Insert and Update الي كتبناهم لحفظ التغييرات ع الجدول بصورة نهائية.
و أيضا كـ administrator لل database لو جعلت two users الهم صلاحية للتعامل مع جدول المنتجات products (من ناحية أضافة و تعديل و حذف منتجات), فلو فرضنا ان ال user الاول غيًر ع محتويات منتج ما ضمن ال products Table يعني يتعامل مع row/record واحد من الجدول, فطالما هو يُغيَر بالمحتويات الuser الثاني لا يمتلك حق يعمل تغييرات ع محتويات هذا المنتج الا اذا ال user الاول عمل Commit او خرج من تطيبيق ال Oracle SQL Developer. لان بالوقت الي ال user الاول يعمل update لهذا المنتج ال database تعمل block لل row/record الي يمثل هذا المنتج فأي user آخر لا يستطيع عمل اي تغيير للحافظ ع دقة المعلومات.
أذن كملخص لهذا الكلام نستنتج أن نتيجة DML statements لا تحفظ نهائيا بقاعدة البيانات الا بعد استخدام امر ال commit.
لكن بالنسبة DDL and DCL Statements الوضع يختلف ما يحتاج نستخدم أمر commit بعدها لحفظ التغييرات لأنهُ يتفعل ضمنيا فالتغييرات الي تحدث كنتيجة لهذه الأوامر تحفظ يكون حفظ نهائي.
- ال DDL تتضمن command تتعامل مع structure of table مثل create, alter, drop, Rename, or truncate والي رح نشرحها في المستقبل.
- و ال DCL statements تتضمن command مثل Grant or Revoke والي ايضا رح نشرحها في المستقبل أن شاء الله.
مثلا موضوع التسوق shopping اونلاين (أي عبر موقع تسوق الكتروني ) ، حاليا توجد العديد من تطبيقات التسوق عبر الانترنيت منها amazone، alibaba و غيرها من التطبيقات. المهم هذه التطبيقات تسمحلك شراء منتج معين اونلاين و الدفع يكون عن طريق البطاقة الائتمانية.
وهذه ال Apps تستخدم Database, وهذا نظام Database يتعاملون معاه فئتين من الناس.
الأولى هم:adminstrators/users أشخاص يتعاملون مع ال database المرتبطة بال application و يقومون بمجموعة من المهام مثلا أضافة منتجات products او التعديل عليها او حذف منتجات موجودة.
و الفئة الثاني: customers/clients أشخاص تتعامل مع ال application المرتبطة بdatabase لتستعرض المنتجات المخزونة بال database لغرض التصفح و شرائها.
فكـ administrator لل database قررت أضافة منتج جديد و عدلت ع سعر او حجم أوقد يكون لون منتج موجود ( يعني أستخدم Insert and Update commands) فخلال الفترة الي اقوم بيها بتنفيذ sql statements الي تقوم بهذا العمل أي شخص client يقوم بأستعراض هذه المنتجات عن طريق ال application رح يشوف النتائج و القيم قبل التغييرات الي قمت بيها لان التغيرات الي صارت هي تغيرات شكليه (فقط آني اشوفها) وليست فعلية (يعني مو الكل يشوفها). طيب لعد متى رح يشوفون التغييرات الي قمت بيها؟ يشوفوها من أكتب و أنفذ الأمر Commit بعد أوامر ال Insert and Update الي كتبناهم لحفظ التغييرات ع الجدول بصورة نهائية.
و أيضا كـ administrator لل database لو جعلت two users الهم صلاحية للتعامل مع جدول المنتجات products (من ناحية أضافة و تعديل و حذف منتجات), فلو فرضنا ان ال user الاول غيًر ع محتويات منتج ما ضمن ال products Table يعني يتعامل مع row/record واحد من الجدول, فطالما هو يُغيَر بالمحتويات الuser الثاني لا يمتلك حق يعمل تغييرات ع محتويات هذا المنتج الا اذا ال user الاول عمل Commit او خرج من تطيبيق ال Oracle SQL Developer. لان بالوقت الي ال user الاول يعمل update لهذا المنتج ال database تعمل block لل row/record الي يمثل هذا المنتج فأي user آخر لا يستطيع عمل اي تغيير للحافظ ع دقة المعلومات.
أذن كملخص لهذا الكلام نستنتج أن نتيجة DML statements لا تحفظ نهائيا بقاعدة البيانات الا بعد استخدام امر ال commit.
لكن بالنسبة DDL and DCL Statements الوضع يختلف ما يحتاج نستخدم أمر commit بعدها لحفظ التغييرات لأنهُ يتفعل ضمنيا فالتغييرات الي تحدث كنتيجة لهذه الأوامر تحفظ يكون حفظ نهائي.
- ال DDL تتضمن command تتعامل مع structure of table مثل create, alter, drop, Rename, or truncate والي رح نشرحها في المستقبل.
- و ال DCL statements تتضمن command مثل Grant or Revoke والي ايضا رح نشرحها في المستقبل أن شاء الله.
2. RollBack
يستخدم للتراجع عن SQL Statements التي تم تنفيذها و لم نعمل لها commit (اي التراجع عن التغييرات التي حدثت للبيانات في الجدول والتي لم تحفظ بصورة نهائية).
مثل ما تلاحظون بالمثال أعلاه عملنا update لل Salary لموظفين موجودين عدنا بال table و بعدها قررت أتراجع عن هذه التغيرات فأستخدمنا ال rollback. لذلك اذا تلاحظون نتيجة ال select statement الاخيرة قيم ال Salary رجعت مثل ما كانت بالبداية لان استخدمنا ال rollback command .
يستخدم للتراجع عن SQL Statements التي تم تنفيذها و لم نعمل لها commit (اي التراجع عن التغييرات التي حدثت للبيانات في الجدول والتي لم تحفظ بصورة نهائية).
مثل ما تلاحظون بالمثال أعلاه عملنا update لل Salary لموظفين موجودين عدنا بال table و بعدها قررت أتراجع عن هذه التغيرات فأستخدمنا ال rollback. لذلك اذا تلاحظون نتيجة ال select statement الاخيرة قيم ال Salary رجعت مثل ما كانت بالبداية لان استخدمنا ال rollback command .
3. Savepoint
يستخدم لأنشاء نقطة حفظ Savepoint معينة لاستخدامها لاحقا في التراجع RollBack بالتغييرات عند هذه النقطة.
أحيانا يهمنا التراجع عن التغييرات الي سويناها بال table من نقطة معينه وليس التراجع عن كل التغيرات الي قمنا بيها.
فبالمثال أعلاه عملنا update لل Salary لل employee الأول و بعدها عملنا update لل Salary لل employee الثاني و بعدين ردت أتراجع عن ال update للي عملته للموظف الثاني فاستخدمت ال savepoint قبل ال update للموظف الثاني و أعطيتها أسم UndoChangeOfEmployee2 (وممكن استخدام اي اسم يعجبنا لكن الأفضل يكون دال ع المعنى) و استخدمت Rollback to SavePoint بعد عبارة ال update للتراجع عن هذه الخطوة لذلك مثل منلاحظ بنتيجة ال Select Statement الأخيرة أصبح ال Salary للموظف الثاني مثل ما كان قبل التغيير Update.
يستخدم لأنشاء نقطة حفظ Savepoint معينة لاستخدامها لاحقا في التراجع RollBack بالتغييرات عند هذه النقطة.
أحيانا يهمنا التراجع عن التغييرات الي سويناها بال table من نقطة معينه وليس التراجع عن كل التغيرات الي قمنا بيها.
فبالمثال أعلاه عملنا update لل Salary لل employee الأول و بعدها عملنا update لل Salary لل employee الثاني و بعدين ردت أتراجع عن ال update للي عملته للموظف الثاني فاستخدمت ال savepoint قبل ال update للموظف الثاني و أعطيتها أسم UndoChangeOfEmployee2 (وممكن استخدام اي اسم يعجبنا لكن الأفضل يكون دال ع المعنى) و استخدمت Rollback to SavePoint بعد عبارة ال update للتراجع عن هذه الخطوة لذلك مثل منلاحظ بنتيجة ال Select Statement الأخيرة أصبح ال Salary للموظف الثاني مثل ما كان قبل التغيير Update.
ذكرنا ضمن تعريف ال transaction بأنها أيضا ممكن تكون مجموعة من العمليات التي تنفذ كحزمة واحدة أما أن تنجح كلها أو تفشل كلها دفعة واحدة, خلي ناخذ مثال يوضح هذا الكلام:
خلي نرجع لموضوع shopping اونلاين فلو فرضنا أن customer معين قرر شراء منتج ما بكمية 1 بقيمة 1000 دولار اونلاين.
لو فرضنا أن عملية البيع تمت بنجاح ( اقصد تم التأكد ان البطاقة الائتمانية تحتوي ع المبلغ الكافي لعملية الشراء و تم سحب المال من البطاقة الائتمانية لل customer و إيداع المبلغ في الحساب الخاص للمتجر أو لموقع التسوق) فالخطوات الي رح تصير بعدها هو مجموعة من الخطوات المتسلسلة ( المترابطه مع بعضها):
1. تقليل كمية هذا المنتج إلى تم شراءه في جدول المنتجات products بمقدار إلي تم طلبه (من خلال أستخدام Update Command).
Update Products Set Product_amount=Product_amount-1 where product_id=33;
2. إضافة ال Id تبع ال customer (خلي نفرضه 1 )إلي قام بالشراء و Id تبع المنتج ( الي فرضناه سابقا 33) إلي تم شراءه إلى جدول الطلبات Orders ( من خلال أستخدام Insert Command).
INSERT INTO orders (user_id, product_id) values (1, 33);
الآن خلونا نتخيل لو أن شئ ما صار بعد تنفيذ ال SQL الاولى و منع من تنفيذ ال SQL الثانية... يعني هنا صارت مشكله كبيرة لأن تم سحب النقود من البطاقة الائتمانية للشخص و تحويلها لحساب الموقع ( لكن المنتجات إلى قرر الشخص شرائها لم تذهب لجدول ال orders يعني مرح يتم شحن المنتجات للشخص و هنا هذه سببت مشكله) و أحيانا يتم شراء منتجات بأسعار عالية جدا فهنا في هذه الحالة فعليا تصير كارثه كبيرة.
لذلك هنا في مثل هذه الحالة لازم نتأكد بأن إما تتنفذ جميع sql Statements بنجاح أو في حال صار فشل في أي أمر يجب إلغاء تنفيذ (كل الأوامر التي تنفذت بنجاح), و حتى نلغي التنفيذ نستخدم الأمر Rollback.
خلي نرجع لموضوع shopping اونلاين فلو فرضنا أن customer معين قرر شراء منتج ما بكمية 1 بقيمة 1000 دولار اونلاين.
لو فرضنا أن عملية البيع تمت بنجاح ( اقصد تم التأكد ان البطاقة الائتمانية تحتوي ع المبلغ الكافي لعملية الشراء و تم سحب المال من البطاقة الائتمانية لل customer و إيداع المبلغ في الحساب الخاص للمتجر أو لموقع التسوق) فالخطوات الي رح تصير بعدها هو مجموعة من الخطوات المتسلسلة ( المترابطه مع بعضها):
1. تقليل كمية هذا المنتج إلى تم شراءه في جدول المنتجات products بمقدار إلي تم طلبه (من خلال أستخدام Update Command).
Update Products Set Product_amount=Product_amount-1 where product_id=33;
2. إضافة ال Id تبع ال customer (خلي نفرضه 1 )إلي قام بالشراء و Id تبع المنتج ( الي فرضناه سابقا 33) إلي تم شراءه إلى جدول الطلبات Orders ( من خلال أستخدام Insert Command).
INSERT INTO orders (user_id, product_id) values (1, 33);
الآن خلونا نتخيل لو أن شئ ما صار بعد تنفيذ ال SQL الاولى و منع من تنفيذ ال SQL الثانية... يعني هنا صارت مشكله كبيرة لأن تم سحب النقود من البطاقة الائتمانية للشخص و تحويلها لحساب الموقع ( لكن المنتجات إلى قرر الشخص شرائها لم تذهب لجدول ال orders يعني مرح يتم شحن المنتجات للشخص و هنا هذه سببت مشكله) و أحيانا يتم شراء منتجات بأسعار عالية جدا فهنا في هذه الحالة فعليا تصير كارثه كبيرة.
لذلك هنا في مثل هذه الحالة لازم نتأكد بأن إما تتنفذ جميع sql Statements بنجاح أو في حال صار فشل في أي أمر يجب إلغاء تنفيذ (كل الأوامر التي تنفذت بنجاح), و حتى نلغي التنفيذ نستخدم الأمر Rollback.