संपादित करें:
<पर ध्यान न दें> इस व्यवहार को देखने का कारण यह है कि, SQL पूर्ण टेक्स्ट खोज के लिए डिफ़ॉल्ट वर्डब्रेकर अंग्रेजी भाषा (लोकेल 1033) द्वारा परिभाषित होते हैं। अंग्रेजी में, अल्पविराम एक मान्य शब्द-विरोधक है, जिससे आपकी संख्या दो अलग-अलग संख्याओं में टूट जाती है। हालाँकि, यदि आप पुर्तगाली शब्द-ब्रेकर का उपयोग करते हैं, तो FTS बड़ी चतुराई से संख्याओं को एक साथ रखता है। यह देखने के लिए अपने SQL सर्वर पर निम्न क्वेरी चलाने का प्रयास करें कि निर्दिष्ट स्थान के आधार पर फ़ुलटेक्स्ट इंजन समान इनपुट को अलग-अलग तरीके से कैसे पार्स करता है:
--use locale English
select * from sys.dm_fts_parser('"12345,10"',1033,NULL,0)
--use locale Portuguese
select * from sys.dm_fts_parser('"12345,10"',2070,NULL,0)
अद्यतन:ठीक है, मैंने आपके परिदृश्य को दोहराने में कामयाबी हासिल की है और हाँ यह SQL सर्वर FTS के साथ डिफ़ॉल्ट व्यवहार प्रतीत होता है। हालांकि, ऐसा लगता है कि यह केवल संख्या के निकटतम 1/10वें (आपके मामले में निकटतम 10 सेंटावो) तक है, न कि निकटतम पूर्ण संख्या तक।
तो उदाहरण के लिए; 12345,88 12345,88 और साथ ही 12345,9 की खोजों में लौटाए जाएंगे , जबकि 56789,98 56789,98 के साथ-साथ 56790 की खोजों में दिखाई देंगे। हालांकि, 45678,60 जैसी कोई संख्या बिना किसी पूर्णांकन के अक्षुण्ण रहेगी, इसलिए यह उतना बुरा नहीं है जितना आप सोचते हैं।
सुनिश्चित नहीं है कि इस व्यवहार को बदलने के लिए आप कुछ भी कर सकते हैं। Google पर एक त्वरित खोज ने कुछ भी नहीं लौटाया।
