এসকিউএল সার্ভারে রেকর্ড মুছে ফেলার পরে পরিচয় বীজ পুনরায় সেট করুন

682

আমি একটি এসকিউএল সার্ভার ডাটাবেস সারণিতে রেকর্ডগুলি .োকিয়েছি। সারণীতে একটি প্রাথমিক কী সংজ্ঞায়িত করা হয়েছিল এবং স্বতঃবৃদ্ধি সনাক্তকরণ বীজটি "হ্যাঁ" এ সেট করা আছে। এটি প্রাথমিকভাবে করা হয় কারণ এসকিউএল অ্যাজুরে, প্রতিটি টেবিলের একটি প্রাথমিক কী এবং পরিচয় সংজ্ঞায়িত করতে হবে।

তবে যেহেতু আমাকে টেবিল থেকে কিছু রেকর্ড মুছতে হবে, সেই টেবিলগুলির জন্য পরিচয় বীজটি বিঘ্নিত হবে এবং সূচী কলাম (যা 1 এর বর্ধনের সাথে স্বয়ংক্রিয়ভাবে উত্পন্ন) বিরক্ত হবে get

আমি রেকর্ডস মুছে ফেলার পরে কীভাবে পরিচয় কলামটি পুনরায় সেট করতে পারি যাতে কলামটি ক্রমবর্ধমান সংখ্যায় ক্রম থাকে?

পরিচয় কলামটি ডাটাবেসের যে কোনও জায়গায় বিদেশী কী হিসাবে ব্যবহৃত হয় না।

sql  sql-server  database  sql-server-2008  azure-sql-database 
— xorpower
সূত্র
4
"এসকিউএল অ্যাজুরেতে" - "প্রতিটি টেবিলের একটি প্রাথমিক কী থাকতে হবে" - সত্য - "এবং পরিচয় সংজ্ঞায়িত" - মিথ্যা। সনাক্তকরণ এবং প্রাথমিক কী হ'ল অর্থোগোনাল ধারণা। একটি পরিচয় কলাম কোনও টেবিলের পিকে হতে হবে না। একটি প্রাথমিক কী পরিচয় কলাম হতে হবে না।
— ড্যামিয়েন_এ_বিশ্বাসীরা
ঠিক আছে. আমার ধারণা ভুল হতে পারে। তবে এখন আমি পিকে এবং আইডেন্টিটি বীজের সাহায্যে টেবিলের কাঠামো সংজ্ঞায়িত করেছি। যদি আমাকে কিছু সারি মুছে ফেলতে হয় তবে আমি কীভাবে একটি পরিচয়
— বীজটিকে
29
আমি সর্বদা তর্ক করব যে আপনি যদি কোনও পরিচয় কলামে উত্পন্ন প্রকৃত সংখ্যাসমূহের প্রতি যত্নশীল হন তবে আপনি সেগুলি অপব্যবহার করছেন। একটি পরিচয় কলামের সাথে আপনার যে সমস্ত যত্ন নেওয়া উচিত তা হ'ল এটি স্বয়ংক্রিয়ভাবে অনন্য মান তৈরি করে (হ্যাঁ!) এবং আপনি এই সংখ্যাগুলিকে একটি সংখ্যাসূচক কলামে সঞ্চয় করতে পারেন (এই বিটটি কেবল এই মানগুলি ধরে রাখতে কলাম ঘোষণার জন্য প্রাসঙ্গিক)। আপনি তাদের কাউকে দেখাচ্ছেন না, তাই তারা কী মান গ্রহণ করবে তা বিবেচ্য নয়।
— ড্যামিয়েন_এ_বিশ্বাসীরা
আপনি অন্যান্য উল্লিখিত হিসাবে সনাক্ত করতে ডিবিসিসি চেক ব্যবহার করতে পারেন তবে দয়া করে নোট করুন যে
— স্কেল

উত্তর:

1099

DBCC CHECKIDENTব্যবস্থাপনা কমান্ড পরিচয় কাউন্টার রিসেট করতে ব্যবহৃত হয়। সিনট্যাক্স কমান্ডটি হ'ল:

DBCC CHECKIDENT (table_name [, { NORESEED | { RESEED [, new_reseed_value ]}}])
[ WITH NO_INFOMSGS ]

উদাহরণ: 

DBCC CHECKIDENT ('[TestTable]', RESEED, 0);
GO

এটি আজুর এসকিউএল ডেটাবেস এর পূর্ববর্তী সংস্করণগুলিতে সমর্থিত ছিল না তবে এটি এখন সমর্থিত।

দয়া করে নোট করুন যে ডকুমেন্টেশন অনুসারেnew_reseed_value এসকিউএল সার্ভার সংস্করণে আর্গুমেন্টটি পরিবর্তিত হয়েছে :

সারণি যদি সারণীতে উপস্থিত থাকে তবে পরের সারিটি new_reseed_value মান সহ সন্নিবেশ করানো হয়। সংস্করণ এসকিউএল সার্ভার ২০০৮ আর 2 এবং এর আগের সংস্করণে, সন্নিবেশিত পরবর্তী সারিতে নতুন_সীমান্ত_মূল্য + বর্তমান বর্ধন মান ব্যবহার করে।

যাইহোক, আমি এই তথ্যটি বিভ্রান্তিমূলক দেখতে পেয়েছি (কেবলমাত্র সরল ভুল প্রকৃত পক্ষে) কারণ পর্যবেক্ষণ করা আচরণটি ইঙ্গিত দেয় যে কমপক্ষে এসকিউএল সার্ভার 2012 এখনও নতুন_আরসিড_মূল্য + বর্তমান বর্ধিত মান যুক্তি ব্যবহার করে। মাইক্রোসফ্ট এমনকি Example Cএকই পৃষ্ঠায় পাওয়া নিজস্ব সাথে বৈপরীত্য :

গ। বর্তমান পরিচয় মানকে একটি নতুন মানতে বাধ্য করা

নিম্নলিখিত উদাহরণটি ঠিকানা টাইপ টেবিলের ঠিকানা টাইপআইডি কলামে বর্তমান পরিচয় মানকে 10 এর মান হিসাবে বাধ্য করে Because যেহেতু সারণীতে বিদ্যমান সারি রয়েছে, সন্নিবেশিত পরবর্তী সারিটি 11 হিসাবে মান হিসাবে ব্যবহার করবে, যা নতুন বর্তমান বর্ধিত মানটির জন্য সংজ্ঞায়িত হবে কলাম মান প্লাস 1।

USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);  
GO

তবুও, এগুলি নতুন এসকিউএল সার্ভার সংস্করণগুলিতে ভিন্ন আচরণের জন্য একটি বিকল্প ছেড়ে দেয়। আমি নিশ্চিত হওয়ার একমাত্র উপায় অনুমান করি, যতক্ষণ না মাইক্রোসফ্ট তার নিজস্ব ডকুমেন্টেশনে জিনিস পরিষ্কার না করে, ব্যবহারের আগে আসল পরীক্ষা করা।

— পেটর আবদুলিন
সূত্র
23
সিনট্যাক্স হবে ... DBCC CHECKIDENT ( '[TestTable], RESEED, 0) গো
— biki
2
দেখা যাচ্ছে যে DBCC CHECKIDENTআসন্ন রিলিজ (V12 / স্টার্লিং) হিসাবে সমর্থিত হয়: azure.microsoft.com/en-us/documentation/articles/... যদিও, এই বিশেষ পরিস্থিতির জন্য, আমার এখনও সুপারিশ করবে truncate টেবিল :)
— সলোমন Rutzky
1
"জিও" অন্য লাইনে না আসা পর্যন্ত এটি আমার পক্ষে কাজ করে না।
— mrówa
1
একই লাইনে জিও কীওয়ার্ডের কারণে সিনট্যাক্সটি পতাকাঙ্কিত হচ্ছে, কেন জানি না। আপনি কি এটিকে এক লাইনের নিচে নামাতে পারবেন? আমি এই লাইনটি 50 বার অনুলিপি করে আটকালাম এবং এখন আমাকে ফিরে গিয়ে এটি ঠিক করতে হবে।
— আরেকটি ডেভেলপার
4
আমার জন্য নিখুঁতভাবে কাজ করেছেন। এটি উল্লেখ করার মতো যে, কোনও টেবিলটি পুনরায় বীজ দেওয়ার সময়, আপনি যদি পুনরায় পুনরায় বিকাশ করতে চান যাতে আপনার প্রথম রেকর্ডটি আইডি 1 হয় তবে পুনরায় পুনঃনির্দেশিত কমান্ডটি 0 এ পুনরায় যুক্ত করা উচিত, যাতে পরের রেকর্ডটি আইডি 1 হয়
— মাইক উপজোঁ
215 
DBCC CHECKIDENT ('TestTable', RESEED, 0)
GO

যেখানে 0 হল identityমান মান

— আনিল শাহ
সূত্র
15
যদি টেবিলটি খালি থাকে, যেমন আপনি সবেমাত্র ডেকেছেন TRUNCATE, তবে নতুন বীজের মানটি পরবর্তী ব্যবহারের মান হওয়া উচিত (যেমন 1 নয় 0)। টেবিলটি খালি না হলে এটি ব্যবহার করবে new_reseed_value + 1। এমএসডিএন
— kjbartel
2
@ কেজেবার্টেল, অনিল এবং অন্যান্যরা: এটি কেবল "টেবিলটি খালি থাকলে" এর মতো সহজ নয়। ডকুমেন্টেশনের ক্ষেত্রে কেসটি অনুপস্থিত ছিল যখন টেবিলটি খালি থাকার কারণে DELETE, না TRUNCATE, এটি ক্ষেত্রেও রয়েছে new_reseed+value + 1। আমি এ সম্পর্কে একটি পোস্ট লিখেছি, কিছু পরীক্ষার মাধ্যমে প্রকৃত আচরণ দেখিয়ে, এবং আসল ডকটি আপডেট করেছি (এখন এটি গিটহাবের কারণে হওয়ার কারণে আমরা করতে পারি): পরিচয় বীজ পুনরায় সেট করার সময় কীভাবে ডিবিসিসি চেকসেন্ট সত্য কাজ করে? ।
— সলোমন রুটজকি
87

এটি লক্ষ করা উচিত যে, যদি সমস্ত ডেটা টেবিল থেকে মুছে ফেলা হচ্ছে DELETE(যেমন কোনও WHEREধারা নেই), তবে যতক্ষণ না ক) অনুমতি এটির অনুমতি দেয়, এবং খ) সারণীতে রেফারেন্স দেওয়ার মতো কোনও এফকে নেই (যা উপস্থিত রয়েছে বলে মনে হয়) এখানে কেস) ব্যবহার TRUNCATE TABLEকরা পছন্দ করা হবে কারণ এটি আরও কার্যকর DELETE এবংIDENTITY একই সাথে বীজ পুনরায় সেট করে । ট্রান্সকেট টেবিলের জন্য নিম্নলিখিত বিবরণগুলি এমএসডিএন পৃষ্ঠা থেকে নেওয়া হয়েছে :

মোছা বিবৃতিটির তুলনায়, ট্র্যাঙ্কেট টেবিলে নিম্নলিখিত সুবিধা রয়েছে:

  • কম লেনদেনের লগ স্পেস ব্যবহার করা হয়।

    মোছা বিবৃতিটি একবারে একটি করে সারিগুলি সরিয়ে দেয় এবং প্রতিটি মুছে ফেলা সারির জন্য লেনদেনের লগে একটি এন্ট্রি রেকর্ড করে। ট্র্যাঙ্কেট টেবিল সারণীর ডেটা সংরক্ষণ করার জন্য ব্যবহৃত ডেটা পৃষ্ঠাগুলিকে অবনতি করে ডেটা সরিয়ে দেয় এবং লেনদেনে লগের মধ্যে কেবল পৃষ্ঠা বিলোপ রেকর্ড করে।

  • কম লক সাধারণত ব্যবহৃত হয়।

    যখন মোছা বিবৃতিটি সারি লক ব্যবহার করে কার্যকর করা হয়, সারণীর প্রতিটি সারি মুছে ফেলার জন্য লক করা থাকে। ট্র্যাঙ্কেট টেবিল সর্বদা সারণিটি (একটি স্কিমা (এসসিএইচ-এম) লক সহ) লক করে তবে প্রতিটি সারিতে নয়।

  • ব্যতিক্রম ছাড়া শূন্য পৃষ্ঠাগুলি সারণীতে রেখে দেওয়া হয়েছে।

    একটি মোছা বিবৃতি কার্যকর করার পরে, সারণীতে এখনও খালি পৃষ্ঠা থাকতে পারে। উদাহরণস্বরূপ, একটি গাদা খালি পৃষ্ঠাগুলি কমপক্ষে একটি এক্সক্লুসিভ (LCK_M_X) টেবিল লক ব্যতীত বিশিষ্ট হওয়া যাবে না। যদি মুছুন অপারেশনটি কোনও টেবিল লক ব্যবহার না করে, সারণীতে (হিপ) অনেকগুলি খালি পৃষ্ঠা থাকবে। সূচকগুলির জন্য, মোছার কাজটি খালি পৃষ্ঠাগুলিকে পিছনে ফেলে রাখতে পারে, যদিও এই পৃষ্ঠাগুলি একটি ব্যাকগ্রাউন্ড ক্লিনআপ প্রক্রিয়া দ্বারা দ্রুত বিলোপ করা হবে।

যদি টেবিলটিতে একটি পরিচয় কলাম থাকে তবে সেই কলামটির কাউন্টারটি কলামের জন্য নির্ধারিত বীজ মানটিতে পুনরায় সেট করা হয়েছে। যদি কোনও বীজ সংজ্ঞায়িত না করা হয়, তবে ডিফল্ট মান 1 ব্যবহার করা হয়। পরিচয় কাউন্টার ধরে রাখতে, পরিবর্তে DELETE ব্যবহার করুন।

সুতরাং নিম্নলিখিত:

DELETE FROM [MyTable];
DBCC CHECKIDENT ('[MyTable]', RESEED, 0);

ঠিক হয়ে যায়:

TRUNCATE TABLE [MyTable];

TRUNCATE TABLEবিধিনিষেধ সম্পর্কিত অতিরিক্ত তথ্যের জন্য দয়া করে ডকুমেন্টেশন (উপরে লিঙ্কিত) দেখুন etc.

— সলোমন রুটজকি
সূত্র
8
সঠিক পরিস্থিতিতে আরও দক্ষ হওয়ার সময়, এটি সর্বদা একটি বিকল্প নয়। সংক্ষিপ্ত বিবরণ এমন কোনও টেবিলে কার্যকর হবে না যার বিপরীতে এফকে সংজ্ঞায়িত করা আছে। এমনকি যখন কোনও নির্ভরশীল রেকর্ড না থাকে, সীমাবদ্ধতা উপস্থিত থাকলে ছাঁটাই ব্যর্থ হবে। এছাড়াও কাটা কাটা জন্য ALTER অনুমতি প্রয়োজন যেখানে ডিলিট শুধুমাত্র ডিলিট প্রয়োজন।
— রোজওয়্যাল
3
@ রোজভেল ট্রু, তবে আমি ইতিমধ্যে আমার উত্তরটি যোগ্য করে রেখেছিলাম যে যথাযথ অনুমতিগুলি হওয়া উচিত। এছাড়াও, প্রশ্নটি সুনির্দিষ্টভাবে বলেছে যে কোনও এফকে নেই। তবে, স্পষ্টতার স্বার্থে, আমি "নো এফকে" সীমাবদ্ধতা নির্দিষ্ট করতে আপডেট করেছি। যে ইশারা জন্য ধন্যবাদ।
— সলোমন রুটজকি
1
কেবল তিরস্কারযোগ্য যে কোনও এফকে কাটা কাটা ব্লক করবে। পিকে বা পরিচয় কলামের অংশ নয় এমন একটি অনন্য বাধার বিরুদ্ধে এফকে রাখা (অস্বাভাবিক হলেও) সম্ভব।
— রোজওয়্যাল
1
@ রোজওয়াল অ্যাগেইন সত্য, তবে এই প্রশ্নটি ধরে নেওয়া যুক্তিসঙ্গত বলে মনে হচ্ছে যে কোনও অনন্য প্রতিবন্ধকতা দেওয়া হয়নি যে কেবলমাত্র ওপেনের বোঝার কারণে পিকে রয়েছে (সঠিক বা না) এটি অ্যাজুরে এসকিউএল ডাটাবেস দ্বারা প্রয়োজনীয়। নির্বিশেষে, আমি অস্পষ্টতা হ্রাস করার জন্য তাই আমি আবার আপডেট করেছি। ধন্যবাদ।
— সলোমন রুটজকি
কোনও টেবিলে বিদেশী কী থাকা এতটা অস্বাভাবিক নয় এবং কোনও বিদেশী কী উপস্থিতি ট্র্যাঙ্কেট টেবিলে নিষিদ্ধ করে। আমি আজকের এই শক্ত পথটি সবেমাত্র আবিষ্কার করেছি যখন আমি টেবিলের উপর ট্র্যাঙ্কেট টেবিল চালানোর চেষ্টা করেছি যেখানে একটি বিদেশী কী রয়েছে যা টেবিলে থাকা অন্য দুটি কলাম এবং বিদেশী টেবিলের একটি অনন্য সূচকগুলির বিরুদ্ধে প্রয়োগ করা হয়।
— ডেভিড এ। গ্রে
83

যদিও বেশিরভাগ উত্তর 0-এ রিসাইড করার পরামর্শ দিচ্ছে, তবে অনেক সময় আমাদের কেবলমাত্র পরবর্তী আইডিতে পুনরায় পুনরায় পুনরায় স্থাপন করা দরকার

declare @max int
select @max=max([Id])from [TestTable]
if @max IS NULL   //check when max is returned as null
  SET @max = 0
DBCC CHECKIDENT ('[TestTable]', RESEED,@max)

এটি টেবিলটি চেক করবে এবং পরবর্তী আইডিতে পুনরায় সেট করবে।

— অটল কিশোর
সূত্র
2
এটি একমাত্র উত্তর যা সময়ের 100% কাজ করে
— বিপরীত প্রকৌশলী
3
কিছুটা খাটো:declare @max int select @max=ISNULL(max([Id]),0) from [TestTable]; DBCC CHECKIDENT ('[TestTable]', RESEED, @max );
— গিলারমো প্রান্দি
61

আমি @anil shahsউত্তর চেষ্টা করেছিলাম এবং এটি পরিচয়টি পুনরায় সেট করে। কিন্তু যখন একটি নতুন সারি wasোকানো হয়েছিল এটি পেয়েছে identity = 2। সুতরাং পরিবর্তে আমি সিনট্যাক্স এ পরিবর্তন করেছি:

DELETE FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED, 0)
GO

তারপরে প্রথম সারিতে পরিচয় = 1 পাবে।

— মিকায়েল ইঞ্জিভার
সূত্র
— stackuser83
16

যদিও বেশিরভাগ উত্তর প্রস্তাব RESEEDদিচ্ছে 0, এবং কেউ কেউ TRUNCATEDএটি টেবিলগুলির ত্রুটি হিসাবে দেখছেন , মাইক্রোসফ্টের একটি সমাধান রয়েছে যা বাদ দেয় নাID

DBCC CHECKIDENT ('[TestTable]', RESEED)

এটি টেবিলটি চেক করবে এবং পরেরটিতে পুনরায় সেট করবে ID। এটি এমএস এসকিউএল 2005 থেকে বর্তমানের জন্য উপলব্ধ।

https://msdn.microsoft.com/en-us/library/ms176057.aspx

— RealSollyM
সূত্র
1
দুর্ভাগ্যক্রমে এটি সত্য নয়। এমএস এসকিউএল 2014 সার্ভারের জন্য সবেমাত্র এটি পরীক্ষা করে।
— আলেহরো
1
প্রকৃতপক্ষে, এটি এসকিউএল ২০১৪-এর ক্ষেত্রে সত্য I
— ড্যানিয়েল ডায়সন
2
এটি এসকিউএল ২০১২-এ আমার জন্য অসামঞ্জস্যপূর্ণভাবে কাজ করে Sometimes বীজ আলসেসির কাজগুলি নির্দিষ্ট করে।
— ড্যান ফিল্ড 13
এসকিউএল ২০১ me-এ আমার জন্য কাজ করে না - এটি কেবল পরিচয় বীজকে যেমন রয়েছে তেমন ছেড়ে দেয়। এটি আমার জন্য একবারে সঠিকভাবে কাজ করতে পারে তবে এটি আমার আঙুলের সমস্যাও হতে পারে। এটি আবার কাজ করতে পারে না
— বিপরীত প্রকৌশলী
বার্তাটি সাফল্যের ইঙ্গিত দেয় Checking identity information: current identity value '[incorrect seed]', current column value '[correct seed]'., তবে নতুন সন্নিবেশের পরেও এটি এখনও ভুল বীজ ব্যবহার করে।
— ডেনজিলো
7

2 কমান্ড জারি কৌতুক করতে পারে

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

প্রথম পরিচয়টি শূন্যে পুনরায় সেট করুন, এবং পরেরটি এটি পরবর্তী উপলব্ধ মান - জ্যাকবকে সেট করবে

— জ্যাকব
সূত্র
2
ডিবিসিসি চেকিডেন্ট ('[টেস্ট টেবিল]', আরএসইইডি) পরবর্তী উপলব্ধ মানের জন্য পুনরায় গবেষণা করছে না
— অটল কিশোর
রেডগেট ডেটা তুলনা করে এই পদ্ধতিটি ব্যবহৃত হয় যখন "পুনরায় গবেষণা করা পরিচয় কলামগুলি" বিকল্পটি চালু করা হয়। আমি এটির ব্যাপকভাবে পরীক্ষা করেছি (আমার অর্থ এসকিউএল কোড, রেডগেট সরঞ্জাম নয়) এবং এটি নির্ভরযোগ্যভাবে কাজ করে। (রেডগেটের সাথে তাদের ট্রায়াল সংস্করণগুলির মাঝে মাঝে ব্যবহারকারী হওয়া ছাড়া আমার আর কোনও সম্পর্ক নেই)
— বিপরীত প্রকৌশলী
6

@jacob

DBCC CHECKIDENT ('[TestTable]', RESEED,0)
DBCC CHECKIDENT ('[TestTable]', RESEED)

আমার জন্য কাজ করেছেন, আমাকে কেবল প্রথমে টেবিল থেকে সমস্ত এন্ট্রি সাফ করতে হবে, তারপরে মুছার পরে উপরেরটি ট্রিগার পয়েন্টে যুক্ত করুন। এখনই আমি যখনই এন্ট্রি ডিলিট করি সেখান থেকে নেওয়া হবে।

— মহাকাব্য
সূত্র
ডিবিসিসি CHECKIDENT মুছে ফেলার পরে কেবল কার্যকর function আপনি পাশাপাশি কাটা কাটা ব্যবহার করতে পারেন। তবে আপনার যদি বাকী ডেটা দরকার হয় তবে এটি ব্যবহার করবেন না। এছাড়াও কাটা রেকর্ড মুছে ফেলা রেকর্ড গণনা দেয় না।
— ব্যবহারকারী 763539
6

Truncate সারণিটি অগ্রাধিকার দেওয়া হয় কারণ এটি রেকর্ডগুলি সাফ করে, কাউন্টারটি পুনরায় সেট করে এবং ডিস্কের স্থানটি পুনরায় দাবি করে।

Deleteএবং CheckIdentকেবল তখনই ব্যবহার করা উচিত যেখানে বিদেশী কীগুলি আপনাকে কাটানো থেকে বিরত রাখে।

— ডায়না ডেভ
সূত্র
5

নতুন আইডি দিয়ে পরিচয় কলামটি পুনরায় সেট করুন ...

DECLARE @MAX INT
SELECT @MAX=ISNULL(MAX(Id),0) FROM [TestTable]

DBCC CHECKIDENT ('[TestTable]', RESEED,@MAX)
— মুকেশ পান্ডে
সূত্র
4

এটি একটি সাধারণ প্রশ্ন এবং উত্তর সর্বদা এক রকম: এটি করবেন না। সনাক্তকরণের মানগুলি স্বেচ্ছাচারী হিসাবে বিবেচনা করা উচিত এবং যেমন, কোনও "সঠিক" অর্ডার নেই।

— বেন থুল
সূত্র
15
এটি উত্পাদন পরিবেশের জন্য সত্য, তবে বিকাশের সময় আমি মনে রাখতে চাই যে নির্দিষ্ট সত্তার একটি নির্দিষ্ট আইডি রয়েছে, যা বীজ স্ক্রিপ্ট থেকে উদ্ভূত। এটি বিকাশে থাকাকালীন ডাটাবেসের মাধ্যমে চলাচল করা আরও সহজ করে তোলে।
— ফ্রাঙ্কোইস বোথা
7
এর মতো উত্তরগুলি সম্পূর্ণ তাত্ত্বিক এবং এগুলি বাস্তব বিশ্বের প্রয়োজনগুলির সাথে কমই মেনে চলে। কীভাবে লোকেরা আপনার ডগমা দিয়ে ব্রেইন ওয়াশ করার পরিবর্তে ওপি প্রশ্নের উত্তর দেয় ...
— সেরজ সাগান
1
ভাল গল্প ভাই. আমার যুক্তিটি হ'ল: আপনি যদি কোনও কলামের মান নির্দিষ্ট করতে চান তবে কলামে এমন কোনও সম্পত্তি বাছাই করবেন না যা এই কাজটি করা কঠিন করে তোলে। কোডের গন্ধটি হ'ল: প্রতিবার আপনি কোনও সারণীতে কোনও রেকর্ড সন্নিবেশ করানোর সময় আপনি পরিচয় কলামের জন্য একটি মান নির্দিষ্ট করেন, আপনার কোনও পরিচয় কলাম নেই। পরিচয়ের পুরো পয়েন্টটি হ'ল সার্ভারটি আপনার জন্য একটি মান তৈরি করে। সুতরাং আপনি যদি সেই সময়টিকে ওভাররাইড করে থাকেন তবে আপনি শূন্য-ব্যয়ের জন্য কিছুই অর্জন করতে পারেন নি। এছাড়াও, বিজ্ঞাপন হোমনেম যুক্তিতে ভাল কাজ।
— বেন থুল
5
আমি অবশ্যই আপনার তর্ক সঙ্গে একমত। মুখের মূল্যের দিকে তাকালে, ওপি অবশ্যই এটি ভুল করছে, তবে পোস্টে আরও গভীরভাবে বলা দরকার নেই যে ওপি তার প্রশ্নের উত্তর পাওয়ার জন্য প্রাসঙ্গিক বলে মনে করেনি। সুতরাং প্রশ্নের উত্তর দিন, এবং উত্তরের অংশ হিসাবে "করণীয় এবং করণীয়" পরামর্শ দিন। যাইহোক, আমি কখনই আপনার চরিত্রকে আক্রমণ করিনি ... বিজ্ঞাপনের হোমেনেম মানে আমি আপনাকে বোকা বা কিছু বলেছিলাম ...
— সেরজ সাগান
1
যদিও বেশিরভাগ ক্ষেত্রে অবশ্যই সত্য, সেখানে এমন কিছু পরিস্থিতি রয়েছে যেখানে কোনও টেবিলটি পুনরায় বীজ করা বৈধ। উদাহরণস্বরূপ, আমি একটি গ্রিনফিল্ড প্রকল্পে কাজ করছি যা পূর্ববর্তীতে বিদ্যমান সারিগুলির জন্য এটি প্রতিস্থাপন করছে তা হিসাব করার জন্য অবশ্যই নির্দিষ্ট বিন্দু থেকে শুরু করতে হবে। আইএমও, বিকাশের সময় গবেষণা করা বৈধ ব্যবহারের ক্ষেত্রে।
— ডেভিড এ গ্রে
3

পরিচয় কলামটি পুনরায় সেট করতে এই স্ক্রিপ্টটি চালান। আপনার দুটি পরিবর্তন করতে হবে। আপনার টেবিল XYZ প্রতিস্থাপন করুন যা আপনাকে আপডেট করতে হবে Z এছাড়াও, পরিচয় কলামের নামটি টেম্প টেবিল থেকে বাদ দেওয়া দরকার। এটি 35,000 সারি এবং 3 কলাম সহ একটি টেবিলে তাত্ক্ষণিক ছিল। স্পষ্টতই, টেবিলটি ব্যাকআপ করুন এবং প্রথমে এটি একটি পরীক্ষার পরিবেশে চেষ্টা করুন।

select * 
into #temp
From tableXYZ

set identity_insert tableXYZ ON

truncate table tableXYZ

alter table #temp drop column (nameOfIdentityColumn)

set identity_insert tableXYZ OFF

insert into tableXYZ
select * from #temp
— ম্যাথু বাইক
সূত্র
3
এটি সম্পূর্ণরূপে সঠিক নয়: SET পরিচয়পত্রটি ভুল জায়গায় রয়েছে। এটি ট্রানসেটের কাছাকাছি যায় না, এটি INSERT INTO এর কাছাকাছি যায় (সুতরাং পরিচয়_ INSERT )। এছাড়াও, এটি কেবল তখনই ব্যবহার করতে হয় যখন ডেটা রাখা দরকার, অন্যথায় এটি কেবলমাত্র একক ট্রান্সকেট স্টেটমেন্ট চালানোর তুলনায় খুব অদক্ষ।
— সলোমন রুটজকি
1 
DBCC CHECKIDENT (<TableName>, reseed, 0)

এটি বর্তমান পরিচয় মান 0 তে সেট করবে।

পরবর্তী মান সন্নিবেশ করানোর সময়, পরিচয় মানটি 1-তে বাড়ানো হয়।

— Bimzee
সূত্র
1

এই সঞ্চিত পদ্ধতিটি ব্যবহার করুন:

IF (object_id('[dbo].[pResetIdentityField]') IS NULL)
  BEGIN
    EXEC('CREATE PROCEDURE [dbo].[pResetIdentityField] AS SELECT 1 FROM DUMMY');
  END
GO

SET  ANSI_NULLS ON
GO
SET  QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[pResetIdentityField]
  @pSchemaName NVARCHAR(1000)
, @pTableName NVARCHAR(1000) AS
DECLARE @max   INT;
DECLARE @fullTableName   NVARCHAR(2000) = @pSchemaName + '.' + @pTableName;

DECLARE @identityColumn   NVARCHAR(1000);

SELECT @identityColumn = c.[name]
FROM sys.tables t
     INNER JOIN sys.schemas s ON t.[schema_id] = s.[schema_id]
     INNER JOIN sys.columns c ON c.[object_id] = t.[object_id]
WHERE     c.is_identity = 1
      AND t.name = @pTableName
      AND s.[name] = @pSchemaName

IF @identityColumn IS NULL
  BEGIN
    RAISERROR(
      'One of the following is true: 1. the table you specified doesn''t have an identity field, 2. you specified an invalid schema, 3. you specified an invalid table'
    , 16
    , 1);
    RETURN;
  END;

DECLARE @sqlString   NVARCHAR(MAX) = N'SELECT @maxOut = max(' + @identityColumn + ') FROM ' + @fullTableName;

EXECUTE sp_executesql @stmt = @sqlString, @params = N'@maxOut int OUTPUT', @maxOut = @max OUTPUT

IF @max IS NULL
  SET @max = 0

print(@max)

DBCC CHECKIDENT (@fullTableName, RESEED, @max)
go

--exec pResetIdentityField 'dbo', 'Table'

শুধু আমার উত্তর ঘুরে দেখা। এসকিএল সার্ভার ২০০৮ r2-এ আমি একটি অদ্ভুত আচরণ পেয়েছি যা সম্পর্কে আপনার সচেতন হওয়া উচিত।

drop table test01

create table test01 (Id int identity(1,1), descr nvarchar(10))

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

delete from test01

execute pResetIdentityField 'dbo', 'test01'

insert into test01 (descr) values('Item 1')

select * from test01

প্রথম নির্বাচন উত্পাদন করে 0, Item 1।

দ্বিতীয়টি উত্পাদন করে 1, Item 1। যদি আপনি টেবিলটি তৈরি হওয়ার ঠিক পরে রিসেটটি কার্যকর করেন তার পরের মান 0 হয় তবে সত্য, আমি মাইক্রোসফ্ট এই জিনিসটি সঠিকভাবে পেতে না পারায় অবাক হই না। আমি এটি আবিষ্কার করেছি কারণ আমার কাছে একটি স্ক্রিপ্ট ফাইল রয়েছে যা রেফারেন্স টেবিলগুলিকে জনপ্রিয় করে তোলে যা আমি মাঝে মাঝে টেবিলগুলি পুনরায় তৈরি করার পরে এবং কখনও কখনও টেবিলগুলি ইতিমধ্যে তৈরি হওয়ার পরে চালিত করি।

— পঁজর
সূত্র
1

এটি করার জন্য আমি নীচের স্ক্রিপ্টটি ব্যবহার করি। এখানে কেবলমাত্র একটি দৃশ্যে এটি একটি "ত্রুটি" তৈরি করবে, এটি হ'ল যদি আপনি সারণী থেকে সমস্ত সারি মুছে ফেলেছেন এবং IDENT_CURRENTবর্তমানে 1 তে সেট করা রয়েছে, যার সাথে সারণীতে কেবল একটি সারি ছিল।

DECLARE @maxID int = (SELECT MAX(ID) FROM dbo.Tbl)
;

IF @maxID IS NULL
    IF (SELECT IDENT_CURRENT('dbo.Tbl')) > 1
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 0)
    ELSE
        DBCC CHECKIDENT ('dbo.Tbl', RESEED, 1)
    ;
ELSE
    DBCC CHECKIDENT ('dbo.Tbl', RESEED, @maxID)
;
— ক্রিস ম্যাক
সূত্র
0

একটি সম্পূর্ণ সারি মুছে ফেলার জন্য এবং পরিচয় গণনাটি পুনরায় সেট করতে আমি এটি ব্যবহার করি (এসকিউএল সার্ভার ২০০৮ আর 2)

USE mydb

-- ##################################################################################################################
-- DANGEROUS!!!! USE WITH CARE
-- ##################################################################################################################

DECLARE
  db_cursor CURSOR FOR
    SELECT TABLE_NAME
      FROM INFORMATION_SCHEMA.TABLES
     WHERE TABLE_TYPE = 'BASE TABLE'
       AND TABLE_CATALOG = 'mydb'

DECLARE @tblname VARCHAR(50)
SET @tblname = ''

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @tblname

WHILE @@FETCH_STATUS = 0
BEGIN
  IF CHARINDEX('mycommonwordforalltablesIwanttodothisto', @tblname) > 0
    BEGIN
      EXEC('DELETE FROM ' + @tblname)
      DBCC CHECKIDENT (@tblname, RESEED, 0)
    END

  FETCH NEXT FROM db_cursor INTO @tblname
END

CLOSE db_cursor
DEALLOCATE db_cursor
GO
— Fandango68
সূত্র
0

আপনি পুরো টেবিলটি পরিষ্কার না করে যদি 0 তে গবেষণা করা খুব কার্যকর হয় না।

অ্যান্টনি রেমন্ডের দেওয়া উত্তর সঠিকভাবে সঠিক। প্রথমে সর্বাধিক পরিচয় কলাম পান, তারপরে সর্বাধিক দিয়ে বীজ করুন।

— আলী সুফিয়ান
সূত্র
0

বিকাশের সময় আমি প্রচুর সংখ্যক টেবিলের জন্য এটি সম্পন্ন করার চেষ্টা করছি এবং এটি একটি কবজ হিসাবে কাজ করে।

DBCC CHECKIDENT('www.newsType', RESEED, 1);
DBCC CHECKIDENT('www.newsType', RESEED);

সুতরাং, আপনি প্রথমে এটি 1 এ সেট করতে বাধ্য করেন, তারপরে আপনি এটিকে সারণীতে উপস্থিত সারিগুলির সর্বোচ্চ সূচীতে সেট করেন। আদর্শের দ্রুত এবং সহজ বিশ্রাম।

— KimvdLinde
সূত্র
-2

এটি লগ স্পেস ব্যবহার না করে সমস্ত রেকর্ড মুছে ফেলার পরিবর্তে ট্র্যাঙ্কেট ব্যবহার করা সর্বদা ভাল ।

যদি আমাদের মুছার প্রয়োজন হয় এবং বীজ পুনরায় সেট করার প্রয়োজন হয় তবে সর্বদা মনে রাখবেন যে যদি টেবিলটি কখনই জনবহুল না হয় এবং আপনি ব্যবহার করেন DBCC CHECKIDENT('tablenem',RESEED,0) তবে এমএসডিএন ডকুমেন্টেশনে বর্ণিত হিসাবে প্রথম রেকর্ডটি পরিচয় = 0 পাবে

আপনার ক্ষেত্রে কেবল সূচিটি পুনর্নির্মাণ করুন এবং পরিচয়ের ধারাবাহিকটি হারাতে উদ্বিগ্ন হবেন না কারণ এটি একটি সাধারণ দৃশ্য।

— আবদুল হান্নান ইজাজ
সূত্র
3
আমার মতামত মতামত মতামত কেবল কিছু রেকর্ড মুছে ফেলা হয় ।
— ড্রামবেগ
6
এটি কেবল সাধারণ ভুল - কাট কাটা ব্যবহার করা <i> সর্বদা </ i> ভাল নয় এবং আসলে কিছুটা, খুব সীমাবদ্ধ এবং নির্দিষ্ট পরিস্থিতিতেই কেবল আরও ভাল। স্বর্গ কাউকে আপনার পরামর্শ অনুসরণ করতে বারণ এবং তারপরে রোলব্যাক করা দরকার।
— Thronk
1
@ থ্রোঙ্ক আপনি কেন বোঝাচ্ছেন যা প্রত্যাশা অনুযায়ী আচরণ করা থেকে TRUNCATEবিরত থাকবে ROLLBACK? রোলব্যাক এখনও রোলস ব্যাক। এমনকি ডিবি সেট করা থাকলেও BULK_LOGGED।
— সলোমন রুটজকি
2
ট্রানসেটটি ডিডিএল অপারেশন এবং এটি লগ ফাইলে লগ হয় না। যদি না এটি লেনদেনের অংশ না হয় (প্রশ্নে বা এই উত্তরের কোথাও উল্লেখ করা হয়নি)। যখনই কেউ কিছু বলেন সর্বদা সত্য, এটি বেশ নিরাপদ বাজি যে তারা ভুল wrong
— থ্রঙ্ক
এটিই কেবলমাত্র উত্তর যে নোটগুলি ক্রমটি আগে ব্যবহৃত হয়েছিল কিনা তার উপর নির্ভর করে RESEED আচরণের মধ্যে একটি পার্থক্য রয়েছে notes একাধিক খালি টেবিল জুড়ে একই মানটির পুনরায় গবেষণা করা হয়েছে , যেখানে কিছু সারণী পূর্বে জনবসতিযুক্ত ছিল, ফলস্বরূপ প্রথম রেকর্ডের জন্য বিভিন্ন প্রাথমিক মানগুলির ।
— সাইমন কোলেম্যান
-4

প্রথম: সনাক্তকরণের নির্দিষ্টকরণ কেবল: "না" >> সেভ ডেটাবেস এক্সিকিউট প্রকল্প

তারপরে: পরিচয়ের নির্দিষ্টকরণ কেবল: "হ্যাঁ" >> ডেটাবেস এক্সিকিউট প্রকল্পটি সংরক্ষণ করুন

আপনার ডেটাবেস আইডি, পিকে >> 1 থেকে শুরু করুন

— প্রতীক প্যাটেল
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.