arithmetischer Überlauf auf MySQL Tabelle sogar nach Erhöhung Säulenlänge

Question

Ich habe einen Verbindungsserver auf MS SQL Server, die eine MySQL-Tabelle mit der folgenden Definition wird geöffnet:

CREATE TABLE `postilion_data_tst` (
    `issuer` varchar(32) DEFAULT '', 
    **`post_tran_id` bigint(12) DEFAULT '0',** 
    `post_tran_cust_id` bigint(8) DEFAULT '0', 
    `settle_entity_id` int(4) DEFAULT '0', 
    `batch_nr` int(4) DEFAULT '0', 
    `settle_cash_req` double DEFAULT '0', 
    `settle_amount_rsp` double DEFAULT '0', 
    `settle_amount_req` double DEFAULT '0', 
    `sink_node_name` varchar(30) DEFAULT '', 
    `tran_postilion_originated` double DEFAULT '0', 
    `tran_completed` double DEFAULT '0', 
    `message_type` varchar(4) DEFAULT '', 
    `tran_type` varchar(2) DEFAULT '', 
    `tran_nr` bigint(8) DEFAULT '0', 
    `system_trace_audit_nr` varchar(6) DEFAULT '', 
    `rsp_code_req` varchar(2) DEFAULT '', 
    `rsp_code_rsp` varchar(2) DEFAULT '', 
    `sponsor_bank` varchar(8) DEFAULT '', 
    `retrieval_reference_nr` varchar(12) DEFAULT '', 
    `datetime_tran_gmt` datetime DEFAULT NULL, 
    `datetime_tran_local` datetime DEFAULT NULL, 
    `datetime_req` datetime DEFAULT NULL, 
    `datetime_rsp` datetime DEFAULT NULL, 
    `realtime_business_date` datetime DEFAULT NULL, 
    `recon_business_date` datetime DEFAULT NULL, 
    `from_account_type` varchar(2) DEFAULT '', 
    `to_account_type` varchar(2) DEFAULT '', 
    `from_account_id` varchar(28) DEFAULT '', 
    `to_account_id` varchar(28) DEFAULT '', 
    `tran_amount_req` double DEFAULT '0', 
    `tran_amount_rsp` double DEFAULT '0', 
    `settle_amount_impact` double DEFAULT '0', 
    `tran_cash_req` double DEFAULT '0', 
    `tran_cash_rsp` double DEFAULT '0', 
    `tran_currency_code` varchar(3) DEFAULT '', 
    `settle_cash_rsp` double DEFAULT '0', 
    `settle_currency_code` varchar(3) DEFAULT '', 
    `tran_reversed` varchar(1) DEFAULT '', 
    `prev_tran_approved` double DEFAULT '0', 
    `source_node_name` varchar(30) DEFAULT '', 
    `pan` varchar(19) DEFAULT '', 
    `card_seq_nr` varchar(3) DEFAULT '', 
    `expiry_date` varchar(4) DEFAULT '', 
    `terminal_id` varchar(8) DEFAULT '', 
    `terminal_owner` varchar(25) DEFAULT '', 
    `merchant_type` varchar(4) DEFAULT '', 
    `card_acceptor_name_loc` varchar(40) DEFAULT '', 
    `totals_group` varchar(12) DEFAULT '', 
    `card_product` varchar(20) DEFAULT '', 
    `region` varchar(3) DEFAULT '' 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 

ich die folgende INSERT-Anweisung ausführen und es scheitert mit

"Msg 8115, Ebene 16, Status 2, Zeile 2 Arithmetischer Überlauffehler beim Konvertieren des Ausdrucks in den Datentyp int. Die Anweisung wurde beendet."

Das Skript ist erfolgreich, wenn ich den Wert, der in die problematische Spalte eingefügt wird, um nur Buchstaben reduziere. RBitte stelle ich die Breite der problematischen Spalte zuvor hatte von 8 bis 12 erhöht

** ZURÜCK - ** post_tran_id Bigint (8) DEFAULT '0', **** ** STROM - ** post_tran_id Bigint (12) DEFAULT '0', ****

INSERT INTO postilion_data_tst (issuer, 
post_tran_id, 
post_tran_cust_id, 
settle_entity_id, 
batch_nr, 
settle_cash_req, 
settle_amount_rsp, 
settle_amount_req, 
sink_node_name, 
tran_postilion_originated, 
. 
. 
. 

SELECT 
'Ecobank', 
**222092009,** 
dbo.post_tran_tab.post_tran_cust_id, 
dbo.post_tran_tab.settle_entity_id, 
dbo.post_tran_tab.batch_nr, 
dbo.post_tran_tab.settle_cash_req, 
dbo.post_tran_tab.settle_amount_rsp, 
... 

Was könnte das Problem sein? Ich denke, dass BIGINT (12) ausreichen würde, um 10 Zeichen zu enthalten.

Answer 1

Bigint (8) und Bigint (12) haben genau den gleichen Datentyp. Der Längenabschnitt der Felddefinition wirkt sich nicht auf die untere und obere Grenze eines Integer-Datentyps aus. Der length-Parameter tritt nur dann ein, wenn für das Feld eine Null-Fill-Eigenschaft festgelegt wurde. In diesem Fall zeigt MySQL führende Nullen an, wenn ein Wert nicht genügend Ziffern hat.

Die MySQL-Dokumentation unter integer data types gibt die untere und obere Grenze des bigint-Feldes an: -9223372036854775808 bzw. 9223372036854775807.

Sie müssen feststellen, ob Ihre Daten außerhalb dieser Grenzwerte liegen oder nicht.

Bitte beachten Sie auch, dass die Fehlermeldung die Konvertierung in int, nicht in bigint erwähnt. Die Zahl in der Stichprobe passt in eine Bigint, passt jedoch nicht in ein int-Feld.

ADDITION

Wenn Sie Ihren myodbc Connector konfiguriert, haben Sie die no bigint option geprüft, die bigint in int konvertiert und diese das Verhalten erklären kann.

Answer 2

Geänderter Datentyp für dieses spezifische Feld in VARCHAR (15). In meinem Fall würde die Problemumgehung die Anwendung nicht negativ beeinflussen, aber möglicherweise nicht in allen Fällen.