Δεν υπάρχει πιο λεπτομερές μήνυμα. Αν το σκεφτείς από τη μεριά της βάσης μάλιστα δεν έχει και νόημα, καθώς τα δεδομένα που θα εισαχθούν είναι αποτέλεσμα ενός query και έτσι δεν υπάρχει πλέον η έννοια της "γραμμής". Μπορεί να είναι αποτέλεσμα join, αριθμητικών πράξεων, aggregations.
Θα μπορούσε ίσως η βάση να σου επιστρέφει τη γραμμή που δεν μπόρεσε να εισάγει αλλά αυτό θα κόστιζε πάρα πολύ. Ο λόγος είναι ότι από τη στιγμή που υπάρχει σφάλμα το INSERT πρέπει να αποτύχει. Το execution plan ενός query μπορεί να είναι αρκετά περίπλοκο και το σημείο στο οποίο γίνεται η μετατροπή από το ένα precision στο άλλο σχεδόν σίγουρα είναι πολύ πριν το βήμα της εγγραφής των δεδομένων. Αντί να υπολογίζει δεδομένα τα οποία έτσι κι αλλιώς θα πετάξει, η βάση απλά διακόπτει το execution χωρίς να προσπαθήσει να δημιουργήσει τις τελικές γραμμές.
Πρώτα πρέπει να καταλήξεις στο τί θα κάνεις με τα δεδομένα που δεν μπορούν να μεταφερθούν και μετά θα βρεις άκρη, καθώς αυτό το stored procedure θα πρέπει να τρέχει συνέχεια και ίσως να χειρίζεται τέτοιες περιπτώσεις κάθε φορά. Αν θεωρείς ότι οι αρχικές εγγραφές είναι "λάθος" θα πρέπει να διορθώσεις τα δεδομένα. Αν οι εγγραφές πρέπει να αποκλειστούν, θα πρέπει να φτιάξεις ένα query που θα κόβει τις εγγραφές με τιμή μεγαλύτερη από την επιτρεπόμενη.
Αν θέλεις να ψάξεις ποιές είναι οι προβληματικές εγγραφές θα πρέπει να χρησιμοποιήσεις queries σαν αυτό που πρότεινε ο Βασίλης. Εγώ βέβαια θα πρότεινα κάτι σαν το
select * from table_a
where log10(column_a)>3
γιατί η LEN επιστρέφει το μήκος του string, αλλά για τη βάση δεν έχει ουσιαστική διαφορά.
Μπορείς επιπλέον να χρησιμοποιήσεις τις πληροφορίες που υπάρχουν για τις στήλες στο INFORMATION_SCHEMA.COLUMNS view για να δεις ποιές εγγραφές δεν μπορούν να μερθούν από μία στήλη σε μία άλλη:
select * from table_a
where log10(column_a)>
(select NUMERIC_PRECISION - NUMERIC_SCALE
from INFORMATION_SCHEMA.COLUMNS
where TABLE_NAME='table_b'
and DATA_TYPE='numeric'
and COLUMN_NAME='column_b')
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos