la dll a ete transferée sur Visual C++ et utilise la derniere version des
source de SQLite (version 3.6.18)
voici le detail des modifications
[3.6.0.1]: remise en place du fetch sur les base SQLite3 ce prend moins de
memoire car une seule ligne est chargée a chaque fois alors que le
mySQLPremier charge toutes les lignes de la requete en memoire. la methode
mySQLFetch a donc retrouvé son ancien code. la dll a ete modifiée au niveau
de fetch, LitCol, LitColParNom, LitLigne.
[3.6.0.0]: modification de la dll pour les versions 3 (SQlite4WD3.dll) qui a
ete transferée en visual c++ avec la derniere versions de la librairie
SQlite) compatible avec les base superieure a 3.5. reprise de l'ensemble du
code pour eliminer les elements inutiles.
donc la classe a changéé ainsi que la dll (SQLite4WD3.dll)
donc il faudrait les reintegrer dans vos projets
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal ROY
Firetox a écrit :
Bonjour, a tous
la dll a ete transferée sur Visual C++ et utilise la derniere version des source de SQLite (version 3.6.18) voici le detail des modifications
[3.6.0.1]: remise en place du fetch sur les base SQLite3 ce prend moins de memoire car une seule ligne est chargée a chaque fois alors que le mySQLPremier charge toutes les lignes de la requete en memoire. la methode mySQLFetch a donc retrouvé son ancien code. la dll a ete modifiée au niveau de fetch, LitCol, LitColParNom, LitLigne.
[3.6.0.0]: modification de la dll pour les versions 3 (SQlite4WD3.dll) qui a ete transferée en visual c++ avec la derniere versions de la librairie SQlite) compatible avec les base superieure a 3.5. reprise de l'ensemble du code pour eliminer les elements inutiles.
donc la classe a changéé ainsi que la dll (SQLite4WD3.dll) donc il faudrait les reintegrer dans vos projets
Bon dev @+
Avant de faire la manip, que faut-il vérifier dans nos programmes, et bases ?
-- Pascal ROY (Service Informatique - SODALEC)
Firetox a écrit :
Bonjour, a tous
la dll a ete transferée sur Visual C++ et utilise la derniere version
des source de SQLite (version 3.6.18)
voici le detail des modifications
[3.6.0.1]: remise en place du fetch sur les base SQLite3 ce prend moins
de memoire car une seule ligne est chargée a chaque fois alors que le
mySQLPremier charge toutes les lignes de la requete en memoire. la
methode mySQLFetch a donc retrouvé son ancien code. la dll a ete
modifiée au niveau de fetch, LitCol, LitColParNom, LitLigne.
[3.6.0.0]: modification de la dll pour les versions 3 (SQlite4WD3.dll)
qui a ete transferée en visual c++ avec la derniere versions de la
librairie SQlite) compatible avec les base superieure a 3.5. reprise de
l'ensemble du code pour eliminer les elements inutiles.
donc la classe a changéé ainsi que la dll (SQLite4WD3.dll)
donc il faudrait les reintegrer dans vos projets
Bon dev
@+
Avant de faire la manip, que faut-il vérifier dans nos programmes,
et bases ?
la dll a ete transferée sur Visual C++ et utilise la derniere version des source de SQLite (version 3.6.18) voici le detail des modifications
[3.6.0.1]: remise en place du fetch sur les base SQLite3 ce prend moins de memoire car une seule ligne est chargée a chaque fois alors que le mySQLPremier charge toutes les lignes de la requete en memoire. la methode mySQLFetch a donc retrouvé son ancien code. la dll a ete modifiée au niveau de fetch, LitCol, LitColParNom, LitLigne.
[3.6.0.0]: modification de la dll pour les versions 3 (SQlite4WD3.dll) qui a ete transferée en visual c++ avec la derniere versions de la librairie SQlite) compatible avec les base superieure a 3.5. reprise de l'ensemble du code pour eliminer les elements inutiles.
donc la classe a changéé ainsi que la dll (SQLite4WD3.dll) donc il faudrait les reintegrer dans vos projets
Bon dev @+
Avant de faire la manip, que faut-il vérifier dans nos programmes, et bases ?
-- Pascal ROY (Service Informatique - SODALEC)
Firetox
Bonjour
Avant de faire la manip, que faut-il vérifier dans nos programmes, et bases ?
si vous utilisez des bases SQLite3 il est preferable de passer dans cette version pour les base 2.X rien n'a changé la methode SQLfetch faisait un code different pour les bases 3
par contre la dll en 3 a ete revue (pas dans son fonctionnement puisque seules quelques methodes on ete touchées MySQLfetch, MySQLLitCol, MySQLLitColParNom, MySQLLitLigne et le code a ete modifié sur la partie fetch et pas sur la partie Premier, suivant.
j'ai fais des tests sur des parcours j'ai lancé des projets en 3 complet et je n'ai pas eu de probleme, j'ai ensuite fait des codes SQLfetch pour voir si le resultat etait correcte
j'ai eu des utilisateurs qui utilisent SQLite4WD3 mais les base etaient créees par d'autres outils et donc il ne pouvaient pas ouvrir la base avec windev mais avec SQLite DataBase Browser 1.3 oui ce qui montre que leur base est en 3.5 maintenant ils peuvent avoir leur base sous windev sans probleme
mise a part le fetch qui a changé il suffit de remplacer la dll SQLite4WD3.dll en sauvegardant l'ancienne et tout devrait fonctionner si vous voulez le fetch au lieu de la manip faite avant sur premier suivant il faut changer la classe et donc refaire l'exe du programme
maintenant cela fonctionne
Bon dev @+
Bonjour
Avant de faire la manip, que faut-il vérifier dans nos programmes,
et bases ?
si vous utilisez des bases SQLite3 il est preferable de passer dans cette
version
pour les base 2.X rien n'a changé la methode SQLfetch faisait un code
different pour les bases 3
par contre la dll en 3 a ete revue (pas dans son fonctionnement puisque
seules quelques methodes on ete touchées
MySQLfetch, MySQLLitCol, MySQLLitColParNom, MySQLLitLigne et le code a ete
modifié sur la partie fetch et pas sur la partie Premier, suivant.
j'ai fais des tests sur des parcours j'ai lancé des projets en 3 complet et
je n'ai pas eu de probleme, j'ai ensuite fait des codes SQLfetch pour voir
si le resultat etait correcte
j'ai eu des utilisateurs qui utilisent SQLite4WD3 mais les base etaient
créees par d'autres outils et donc il ne pouvaient pas ouvrir la base avec
windev mais avec SQLite DataBase Browser 1.3 oui ce qui montre que leur base
est en 3.5 maintenant ils peuvent avoir leur base sous windev sans probleme
mise a part le fetch qui a changé il suffit de remplacer la dll
SQLite4WD3.dll en sauvegardant l'ancienne et tout devrait fonctionner si
vous voulez le fetch au lieu de la manip faite avant sur premier suivant il
faut changer la classe et donc refaire l'exe du programme
Avant de faire la manip, que faut-il vérifier dans nos programmes, et bases ?
si vous utilisez des bases SQLite3 il est preferable de passer dans cette version pour les base 2.X rien n'a changé la methode SQLfetch faisait un code different pour les bases 3
par contre la dll en 3 a ete revue (pas dans son fonctionnement puisque seules quelques methodes on ete touchées MySQLfetch, MySQLLitCol, MySQLLitColParNom, MySQLLitLigne et le code a ete modifié sur la partie fetch et pas sur la partie Premier, suivant.
j'ai fais des tests sur des parcours j'ai lancé des projets en 3 complet et je n'ai pas eu de probleme, j'ai ensuite fait des codes SQLfetch pour voir si le resultat etait correcte
j'ai eu des utilisateurs qui utilisent SQLite4WD3 mais les base etaient créees par d'autres outils et donc il ne pouvaient pas ouvrir la base avec windev mais avec SQLite DataBase Browser 1.3 oui ce qui montre que leur base est en 3.5 maintenant ils peuvent avoir leur base sous windev sans probleme
mise a part le fetch qui a changé il suffit de remplacer la dll SQLite4WD3.dll en sauvegardant l'ancienne et tout devrait fonctionner si vous voulez le fetch au lieu de la manip faite avant sur premier suivant il faut changer la classe et donc refaire l'exe du programme
maintenant cela fonctionne
Bon dev @+
Pascal ROY
Firetox a écrit :
Bonjour
Avant de faire la manip, que faut-il vérifier dans nos programmes, et bases ?
si vous utilisez des bases SQLite3 il est preferable de passer dans cette version pour les base 2.X rien n'a changé la methode SQLfetch faisait un code different pour les bases 3
par contre la dll en 3 a ete revue (pas dans son fonctionnement puisque seules quelques methodes on ete touchées MySQLfetch, MySQLLitCol, MySQLLitColParNom, MySQLLitLigne et le code a ete modifié sur la partie fetch et pas sur la partie Premier, suivant.
j'ai fais des tests sur des parcours j'ai lancé des projets en 3 complet et je n'ai pas eu de probleme, j'ai ensuite fait des codes SQLfetch pour voir si le resultat etait correcte
j'ai eu des utilisateurs qui utilisent SQLite4WD3 mais les base etaient créees par d'autres outils et donc il ne pouvaient pas ouvrir la base avec windev mais avec SQLite DataBase Browser 1.3 oui ce qui montre que leur base est en 3.5 maintenant ils peuvent avoir leur base sous windev sans probleme
mise a part le fetch qui a changé il suffit de remplacer la dll SQLite4WD3.dll en sauvegardant l'ancienne et tout devrait fonctionner si vous voulez le fetch au lieu de la manip faite avant sur premier suivant il faut changer la classe et donc refaire l'exe du programme
maintenant cela fonctionne
Bon dev @+
Je viens de télécharger la nouvelle version... Est-ce normal que les date de modification des fichiers n'est pas changées ?
-- Pascal ROY (Service Informatique - SODALEC)
Firetox a écrit :
Bonjour
Avant de faire la manip, que faut-il vérifier dans nos programmes,
et bases ?
si vous utilisez des bases SQLite3 il est preferable de passer dans
cette version
pour les base 2.X rien n'a changé la methode SQLfetch faisait un code
different pour les bases 3
par contre la dll en 3 a ete revue (pas dans son fonctionnement puisque
seules quelques methodes on ete touchées
MySQLfetch, MySQLLitCol, MySQLLitColParNom, MySQLLitLigne et le code a
ete modifié sur la partie fetch et pas sur la partie Premier, suivant.
j'ai fais des tests sur des parcours j'ai lancé des projets en 3 complet
et je n'ai pas eu de probleme, j'ai ensuite fait des codes SQLfetch pour
voir si le resultat etait correcte
j'ai eu des utilisateurs qui utilisent SQLite4WD3 mais les base etaient
créees par d'autres outils et donc il ne pouvaient pas ouvrir la base
avec windev mais avec SQLite DataBase Browser 1.3 oui ce qui montre que
leur base est en 3.5 maintenant ils peuvent avoir leur base sous windev
sans probleme
mise a part le fetch qui a changé il suffit de remplacer la dll
SQLite4WD3.dll en sauvegardant l'ancienne et tout devrait fonctionner si
vous voulez le fetch au lieu de la manip faite avant sur premier suivant
il faut changer la classe et donc refaire l'exe du programme
maintenant cela fonctionne
Bon dev
@+
Je viens de télécharger la nouvelle version...
Est-ce normal que les date de modification des
fichiers n'est pas changées ?
Avant de faire la manip, que faut-il vérifier dans nos programmes, et bases ?
si vous utilisez des bases SQLite3 il est preferable de passer dans cette version pour les base 2.X rien n'a changé la methode SQLfetch faisait un code different pour les bases 3
par contre la dll en 3 a ete revue (pas dans son fonctionnement puisque seules quelques methodes on ete touchées MySQLfetch, MySQLLitCol, MySQLLitColParNom, MySQLLitLigne et le code a ete modifié sur la partie fetch et pas sur la partie Premier, suivant.
j'ai fais des tests sur des parcours j'ai lancé des projets en 3 complet et je n'ai pas eu de probleme, j'ai ensuite fait des codes SQLfetch pour voir si le resultat etait correcte
j'ai eu des utilisateurs qui utilisent SQLite4WD3 mais les base etaient créees par d'autres outils et donc il ne pouvaient pas ouvrir la base avec windev mais avec SQLite DataBase Browser 1.3 oui ce qui montre que leur base est en 3.5 maintenant ils peuvent avoir leur base sous windev sans probleme
mise a part le fetch qui a changé il suffit de remplacer la dll SQLite4WD3.dll en sauvegardant l'ancienne et tout devrait fonctionner si vous voulez le fetch au lieu de la manip faite avant sur premier suivant il faut changer la classe et donc refaire l'exe du programme
maintenant cela fonctionne
Bon dev @+
Je viens de télécharger la nouvelle version... Est-ce normal que les date de modification des fichiers n'est pas changées ?
-- Pascal ROY (Service Informatique - SODALEC)
Firetox
Bonjour,
Je viens de télécharger la nouvelle version... Est-ce normal que les date de modification des fichiers n'est pas changées ?
tu as eu un zip ou un exe ? car le bon est l'exe as tu installé sur un rep ou il y avait deja le projet exemple car il est possible qu'il n'ecrase pas il faut que je vois cela avec innoSetup au cas ou
Je viens de télécharger la nouvelle version...
Est-ce normal que les date de modification des
fichiers n'est pas changées ?
tu as eu un zip ou un exe ? car le bon est l'exe
as tu installé sur un rep ou il y avait deja le projet exemple car il est
possible qu'il n'ecrase pas il faut que je vois cela avec innoSetup au cas
ou
sinon le lien :
http://www.sqlmanagerx.com/SQLManagerX/accesNatifs/SQLite4WD/SQLite4WD%20Install.exe
Je viens de télécharger la nouvelle version... Est-ce normal que les date de modification des fichiers n'est pas changées ?
tu as eu un zip ou un exe ? car le bon est l'exe as tu installé sur un rep ou il y avait deja le projet exemple car il est possible qu'il n'ecrase pas il faut que je vois cela avec innoSetup au cas ou
Je viens de télécharger la nouvelle version... Est-ce normal que les date de modification des fichiers n'est pas changées ?
tu as eu un zip ou un exe ? car le bon est l'exe as tu installé sur un rep ou il y avait deja le projet exemple car il est possible qu'il n'ecrase pas il faut que je vois cela avec innoSetup au cas ou
Je viens de télécharger la nouvelle version...
Est-ce normal que les date de modification des
fichiers n'est pas changées ?
tu as eu un zip ou un exe ? car le bon est l'exe
as tu installé sur un rep ou il y avait deja le projet exemple car il
est possible qu'il n'ecrase pas il faut que je vois cela avec innoSetup
au cas ou
sinon le lien :
http://www.sqlmanagerx.com/SQLManagerX/accesNatifs/SQLite4WD/SQLite4WD%20Install.exe
Je viens de télécharger la nouvelle version... Est-ce normal que les date de modification des fichiers n'est pas changées ?
tu as eu un zip ou un exe ? car le bon est l'exe as tu installé sur un rep ou il y avait deja le projet exemple car il est possible qu'il n'ecrase pas il faut que je vois cela avec innoSetup au cas ou
j'ai vu qu'il trainait j'ai donc verifié tous les liens et supprimé le zip qui n'a plus lieu d'être comme cela il ne reste qu'un seul fichier sur le site (le bon)
Bon dev @+
Bonjour,
un ZIP ! :-(
Je récupère grâce à ton lien ! ;-)
--
Pascal ROY
(Service Informatique - SODALEC)
j'ai vu qu'il trainait j'ai donc verifié tous les liens et supprimé le zip
qui n'a plus lieu d'être
comme cela il ne reste qu'un seul fichier sur le site (le bon)
j'ai vu qu'il trainait j'ai donc verifié tous les liens et supprimé le zip qui n'a plus lieu d'être comme cela il ne reste qu'un seul fichier sur le site (le bon)
Bon dev @+
Pascal ROY
Firetox a écrit :
Bonjour,
un ZIP ! :-( Je récupère grâce à ton lien ! ;-)
-- Pascal ROY (Service Informatique - SODALEC)
j'ai vu qu'il trainait j'ai donc verifié tous les liens et supprimé le zip qui n'a plus lieu d'être comme cela il ne reste qu'un seul fichier sur le site (le bon)
Bon dev @+
Je ne sais pas si c'est lié à la nouvelle version, mais hier j'ai eu 2 fois une erreur sur le SQLFerme suite à des SQLUpdate le numéro de la requête était à -1 !
-- Pascal ROY (Service Informatique - SODALEC)
Firetox a écrit :
Bonjour,
un ZIP ! :-(
Je récupère grâce à ton lien ! ;-)
--
Pascal ROY
(Service Informatique - SODALEC)
j'ai vu qu'il trainait j'ai donc verifié tous les liens et supprimé le
zip qui n'a plus lieu d'être
comme cela il ne reste qu'un seul fichier sur le site (le bon)
Bon dev
@+
Je ne sais pas si c'est lié à la nouvelle version, mais hier
j'ai eu 2 fois une erreur sur le SQLFerme suite à des SQLUpdate
le numéro de la requête était à -1 !
j'ai vu qu'il trainait j'ai donc verifié tous les liens et supprimé le zip qui n'a plus lieu d'être comme cela il ne reste qu'un seul fichier sur le site (le bon)
Bon dev @+
Je ne sais pas si c'est lié à la nouvelle version, mais hier j'ai eu 2 fois une erreur sur le SQLFerme suite à des SQLUpdate le numéro de la requête était à -1 !
-- Pascal ROY (Service Informatique - SODALEC)
Firetox
Bonjour,
Je ne sais pas si c'est lié à la nouvelle version, mais hier j'ai eu 2 fois une erreur sur le SQLFerme suite à des SQLUpdate le numéro de la requête était à -1 ! -- Pascal ROY (Service Informatique - SODALEC)
c'est dans la classe SQLManagerX en fait c'est un update fait sans lock (ce qui ne se produit pas en V5 car le lock est fait avant update)
normalement pour vaire un update il faut faire un lock avant
SQLLitBloque() SQLupdate()
si tu envoie SQLupdate seul le n° de req sur le lock = -1 et boom
je vais mettre une nouvelle version qui fera quand meme l'update meme s'il n'y a pas eu de lock avant
Bonjour,
Je ne sais pas si c'est lié à la nouvelle version, mais hier
j'ai eu 2 fois une erreur sur le SQLFerme suite à des SQLUpdate
le numéro de la requête était à -1 !
--
Pascal ROY
(Service Informatique - SODALEC)
c'est dans la classe SQLManagerX
en fait c'est un update fait sans lock (ce qui ne se produit pas en V5 car
le lock est fait avant update)
normalement pour vaire un update il faut faire un lock avant
SQLLitBloque()
SQLupdate()
si tu envoie SQLupdate seul le n° de req sur le lock = -1 et boom
je vais mettre une nouvelle version qui fera quand meme l'update meme s'il
n'y a pas eu de lock avant
Je ne sais pas si c'est lié à la nouvelle version, mais hier j'ai eu 2 fois une erreur sur le SQLFerme suite à des SQLUpdate le numéro de la requête était à -1 ! -- Pascal ROY (Service Informatique - SODALEC)
c'est dans la classe SQLManagerX en fait c'est un update fait sans lock (ce qui ne se produit pas en V5 car le lock est fait avant update)
normalement pour vaire un update il faut faire un lock avant
SQLLitBloque() SQLupdate()
si tu envoie SQLupdate seul le n° de req sur le lock = -1 et boom
je vais mettre une nouvelle version qui fera quand meme l'update meme s'il n'y a pas eu de lock avant
Firetox
Bonjour;
petit rappel sur SQLManagerX pour bien comprendre ou est l'erreur
SQLLitBloque ouvre une transaction et la laisse ouverte SQLupdate fait l'update et ferme la transaction
avec cela l'enreg bloqué est bloqué jusuq'a update ou autre commande qui feront un rollBack (SQLupdate faisant un commit si tout c'est bien passé) pour liberer l'enregistrement
maintenant si tu veux manipuler update sans lock il faut desactiver les transctions est les gerer toi a saovir
c_SQLManagerX::TransactionDesactive() permet de desactiver les transaction de façon globale ensuite avec l'acces natif tu gere tes transaction et SQLupdate ne fera plus l'erreur
c_SQLManagerX::TransactionActive() sinon en mode SQLManagerX pure il faut passer par SQLitBloque
c'est pour cela que les methodes sont passées en globale pour le faire facilement sur tous les objets SQLManagerX
Bonjour;
petit rappel sur SQLManagerX pour bien comprendre ou est l'erreur
SQLLitBloque ouvre une transaction et la laisse ouverte
SQLupdate fait l'update et ferme la transaction
avec cela l'enreg bloqué est bloqué jusuq'a update ou autre commande qui
feront un rollBack (SQLupdate faisant un commit si tout c'est bien passé)
pour liberer l'enregistrement
maintenant si tu veux manipuler update sans lock il faut desactiver les
transctions est les gerer toi a saovir
c_SQLManagerX::TransactionDesactive() permet de desactiver les transaction
de façon globale
ensuite avec l'acces natif tu gere tes transaction et SQLupdate ne fera plus
l'erreur
c_SQLManagerX::TransactionActive()
sinon en mode SQLManagerX pure il faut passer par SQLitBloque
c'est pour cela que les methodes sont passées en globale pour le faire
facilement sur tous les objets SQLManagerX
petit rappel sur SQLManagerX pour bien comprendre ou est l'erreur
SQLLitBloque ouvre une transaction et la laisse ouverte SQLupdate fait l'update et ferme la transaction
avec cela l'enreg bloqué est bloqué jusuq'a update ou autre commande qui feront un rollBack (SQLupdate faisant un commit si tout c'est bien passé) pour liberer l'enregistrement
maintenant si tu veux manipuler update sans lock il faut desactiver les transctions est les gerer toi a saovir
c_SQLManagerX::TransactionDesactive() permet de desactiver les transaction de façon globale ensuite avec l'acces natif tu gere tes transaction et SQLupdate ne fera plus l'erreur
c_SQLManagerX::TransactionActive() sinon en mode SQLManagerX pure il faut passer par SQLitBloque
c'est pour cela que les methodes sont passées en globale pour le faire facilement sur tous les objets SQLManagerX
Pascal ROY
Firetox a écrit :
Bonjour;
petit rappel sur SQLManagerX pour bien comprendre ou est l'erreur
SQLLitBloque ouvre une transaction et la laisse ouverte SQLupdate fait l'update et ferme la transaction
avec cela l'enreg bloqué est bloqué jusuq'a update ou autre commande qui feront un rollBack (SQLupdate faisant un commit si tout c'est bien passé) pour liberer l'enregistrement
maintenant si tu veux manipuler update sans lock il faut desactiver les transctions est les gerer toi a saovir
c_SQLManagerX::TransactionDesactive() permet de desactiver les transaction de façon globale ensuite avec l'acces natif tu gere tes transaction et SQLupdate ne fera plus l'erreur
c_SQLManagerX::TransactionActive() sinon en mode SQLManagerX pure il faut passer par SQLitBloque
c'est pour cela que les methodes sont passées en globale pour le faire facilement sur tous les objets SQLManagerX
OK, merci.
-- Pascal ROY (Service Informatique - SODALEC)
Firetox a écrit :
Bonjour;
petit rappel sur SQLManagerX pour bien comprendre ou est l'erreur
SQLLitBloque ouvre une transaction et la laisse ouverte
SQLupdate fait l'update et ferme la transaction
avec cela l'enreg bloqué est bloqué jusuq'a update ou autre commande qui
feront un rollBack (SQLupdate faisant un commit si tout c'est bien
passé) pour liberer l'enregistrement
maintenant si tu veux manipuler update sans lock il faut desactiver les
transctions est les gerer toi a saovir
c_SQLManagerX::TransactionDesactive() permet de desactiver les
transaction de façon globale
ensuite avec l'acces natif tu gere tes transaction et SQLupdate ne fera
plus l'erreur
c_SQLManagerX::TransactionActive()
sinon en mode SQLManagerX pure il faut passer par SQLitBloque
c'est pour cela que les methodes sont passées en globale pour le faire
facilement sur tous les objets SQLManagerX
petit rappel sur SQLManagerX pour bien comprendre ou est l'erreur
SQLLitBloque ouvre une transaction et la laisse ouverte SQLupdate fait l'update et ferme la transaction
avec cela l'enreg bloqué est bloqué jusuq'a update ou autre commande qui feront un rollBack (SQLupdate faisant un commit si tout c'est bien passé) pour liberer l'enregistrement
maintenant si tu veux manipuler update sans lock il faut desactiver les transctions est les gerer toi a saovir
c_SQLManagerX::TransactionDesactive() permet de desactiver les transaction de façon globale ensuite avec l'acces natif tu gere tes transaction et SQLupdate ne fera plus l'erreur
c_SQLManagerX::TransactionActive() sinon en mode SQLManagerX pure il faut passer par SQLitBloque
c'est pour cela que les methodes sont passées en globale pour le faire facilement sur tous les objets SQLManagerX