Erreur de débordement Python lors de la transmission de variables à la fonction

Question

J'ai une requête qui obtient un nombre arbitraire de lignes de la base de données, mais généralement pas plus de deux.

J'appelle la requête avec

ret = self.workaround.delete_last_version(pdf_file, self.cust_id, self.part_id) 

Si je hardcode les valeurs et les intégrer dans la requête, il fonctionne très bien, mais quand je lance normalement tout le programme, et saisissez les données à travers une interface utilisateur graphique, Je reçois lorsque la fonction de requête est appelée

OverflowError: long too big to convert 

Cependant, avant que l'appel est fait, je convertir part_id et cust_id à cordes avec str()

Voici les valeurs que je J'ai testé avec.

part_id = "168440901713431956015724879141" 
cust_id = "15424322074155018763160235136213" 
pdf_file = "1971-48.pdf" 

Le cust_id est de 32 caractères de long et part_id est 30

Et voici la requête.

query = """ 
    SELECT Id, Name, DocDateStamp, Dir_Id 
    FROM SdmDocumentList 
    WHERE Owner_Id = ? AND Name = ? 
    ORDER BY DocDateStamp desc 
    """ 

    self.cursor.execute(query, (part_id, pdf_file)) 
    result = self.cursor.fetchall() 

Et le curseur est défini dans __init__

def __init__(self): 

    self.conn =pyodbc.connect('DRIVER=SQL Server;SERVER=mssql;PORT=CORRECTPORT;DATABASE=DATABASENAME;UID=USER;PWD=SUPERSECRETPASSWORD;TDS_Version=8.0;Trusted_Connection=no') #windows 
    self.cursor = self.conn.cursor() 

La sortie attendue, que je reçois quand je l'appelle la fonction de la ligne de commande

[('70D8B606A5BD421F97467F2C8D1D8F04', '1971-48.pdf', datetime.datetime(2017, 5, 12, 9, 28, 58, 743333), 9), 
('F049665629814B83B63B0536F985090B', '1971-48.pdf', datetime.datetime(2017, 5, 12, 9, 28, 22, 86666), 9), 
('39EAB6B173B745E19BA8A0598AD8F015', '1971-48.pdf', datetime.datetime(2017, 5, 12, 9, 27, 58, 933333), 9), 
('6309915CEA504839A8D7340F9A4FD601', '1971-48.pdf', datetime.datetime(2017, 5, 12, 9, 12, 26, 36666), 9), 
('5D3E3AA218CA4FF59E8EC2DE2A6AB217', '1971-48.pdf', datetime.datetime(2017, 5, 12, 9, 11, 37, 760000), 9), 
('1C2AC1073E754A41A998DF99BD0F4F48', '1971-48.pdf', datetime.datetime(2017, 5, 12, 9, 10, 49, 986666), 9), 
('05EF8020EA354E669D1D930650FBCB02', '1971-48.pdf', datetime.datetime(2017, 5, 12, 8, 54, 59, 80000), 9), 
('834979EFB639466ABC73E76F88DF6750', '1971-48.pdf', datetime.datetime(2017, 5, 12, 8, 54, 5, 46666), 9), 
('F3EF2C75856E4926A52204EBA59072CB', '1971-48.pdf', datetime.datetime(2017, 5, 12, 8, 50, 38, 406666), 9), 
('6F7FC2652E114162AF6B3C4C30818582', '1971-48.pdf', datetime.datetime(2017, 5, 12, 8, 37, 59, 610000), 9)] 

Je suis en cours d'exécution python2.7 sur Windows7 64bit et 6 Go de RAM, avec mssql

J'ai googlé et regardé o d'autres problèmes avec OverflowErrors et longs étant trop longs à convertir, mais aucune des solutions postées ne semblait résoudre mon problème, et tous les problèmes que j'ai trouvés sur Internet avaient longtemps été convertis en un autre type numérique. À la ligne, j'obtiens l'erreur, je n'essaie même pas de convertir quoi que ce soit, je passe simplement les variables à une fonction.

Y a-t-il une limite de mémoire sur la quantité de données pouvant être envoyée à une fonction en Python, ou est-ce que quelque chose d'autre me manque?

Plus qu'heureux de fournir plus d'informations si nécessaire, mais je pense que j'ai écrit tout ce qui serait nécessaire pour cela.

Merci à l'avance pour toute aide

EDIT requête qui échoue après la mise à jour pyodbc:

La nouvelle requête qui est à l'origine des problèmes après la mise à jour pyodbc

Dir_Id = 9        # Manufactering Data folder (from SdmDirSructure) 
     DocumentType_RecNo = 3     # PDF 
     OwnerType_RecNo = 2      # parent_id for Product (from SdmDirSructure) 
     FromTo = 14872094126171117726173141183125  # CNCDrill user ID 
     DocumentSubject_RecNo = 109    # Xcheck data (from SdmDocumentSubjects) 
     Owner_Id = self.part_id     # It is the part id 
     DocDateStamp = file_datetime   # datetime of the document 
     RegisteredDate = file_datetime   # when the document was added to the doc manager 
     LastReadDate = file_datetime   # date that the document last readed (set as the RegisteredDate) 
     ArchiveLocation_RecNo = 0    # Not in use 
     IsReceived = True      # Not in use 
     IsArchived = False      # Not in use 
     IsOwnedByUser = 0      # No-one ownes the file 

     query = """ 
     INSERT INTO SdmDocumentList (Id, Name, Dir_Id, DocumentType_RecNo, OwnerType_RecNo, FromTo, DocumentSubject_RecNo, Owner_Id, DocDateStamp, RegisteredDate, LastReadDate, ArchiveLocation_RecNo, IsReceived, IsArchived, IsOwnedByUser, IsClassified) 
     VALUES(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) 
     """ 
     self.cursor.execute(query, (uid,pdf_file, Dir_Id, DocumentType_RecNo, OwnerType_RecNo, FromTo, DocumentSubject_RecNo,Owner_Id, DocDateStamp, RegisteredDate, LastReadDate, ArchiveLocation_RecNo, IsReceived, IsArchived, IsOwnedByUser, IsClassified)) 
     self.cursor.commit() 

Answer 1

FromTo = 14872094126171117726173141183125  # CNCDrill user ID 

Le cuplrit. Finalement, j'ai commencé à imprimer chaque variable et son type. Il s'avère que là où j'avais codé en dur la variable 'FromTo', qui ne changerait jamais, pour ce script, j'avais oublié de le mettre "" autour de lui, ce qui en faisait un long, ce qui plantait la requête.

Je me suis rendu compte que lorsque je récupérais les identifiants de pièces et de clients dans la base de données, ils les renvoyaient en Unicode. J'ai fait quelques recherches sur Unicode, et essayé des alternatives, telles que la définition de l'encodage en haut du script, mais elles n'ont pas fonctionné.Cependant, cela m'a conduit sur le bon chemin de vérifier que chaque variable était le type que je m'attendais.

Merci pour toute l'aide vendredi, @Gord Thompson mai