J'utilise RODBC pour envoyer des requêtes à un serveur SQL. Parfois, leur exécution prend trop de temps, je dois donc les annuler.
Cliquer sur le bouton rouge "stop" dans RStudio génère ce message d'erreur:
R ne répond pas à votre demande d'interrompre le traitement. Pour arrêter l'opération en cours, vous devrez peut-être mettre fin à R complètement.
L'arrêt de R entraînera l'interruption immédiate de votre session R. Les calculs actifs seront interrompus et les modifications du fichier source non enregistrées et les objets de l'espace de travail seront ignorés.
Voulez-vous mettre fin à R maintenant?
Et si je clique sur oui, ma session est en effet terminée. (Remarque: l'utilisation de Rgui au lieu de RStudio n'améliore pas les choses)
Pourtant:
lorsque j'utilise un autre logiciel (nommé "Query ExPlus") pour me connecter à ce même SQL-Server, j'ai un bouton d'arrêt similaire, et cliquer dessus interrompt instantanément la requête, sans aucun crash.
lorsque je me connecte à une base de données PostgreSQL à l'aide du package RPostgres, je peux également interrompre la requête à tout moment.
Ces deux points m'amènent à penser qu'il devrait y avoir un moyen de résoudre mon problème. Que puis-je faire?
Jusqu'à présent, ma solution est la suivante:
library(RODBC)
library(R.utils)
withTimeout(mydf <- sqlQuery(myconnection, myquery), timeout=120)
Note: Je n'ai pas la permission de tuer les requêtes du côté base de données.
Je suis juste tombé sur le paquet odbc
. Il permet d'interrompre une requête à tout moment.
L'utilisation de base va comme ceci:
library(DBI)
myconnection <- dbConnect(odbc::odbc(),
driver = "SQL Server",
server = "my_server_IP_address",
database = "my_DB_name",
uid = "my_user_id",
pwd = "my_password")
dbGetQuery(myconnection, myquery)
Je n'ai pas une compréhension approfondie de ce qui se passe dans les coulisses, mais pour ce que j'ai vu jusqu'à présent dans mon utilisation personnelle, ce package a d'autres avantages par rapport à RODBC
:
stringsAsFactors
et as.is
arguments nécessairesLa plupart des utilisateurs de SQL Server utilisent SQL Server Management Studio (qui est gratuit et peut être téléchargé depuis Microsoft) pour se connecter à SQL Server ou exécuter des commandes à partir de la ligne de commande via un outil appelé SQLCMD.
Si vous pouvez déterminer l'ID de session dans lequel la commande SQL est exécutée, vous pouvez tuer la session qui arrêterait toute commande en cours d'exécution. SQL Server aura toujours besoin de temps (ce qui peut être "long") pour annuler toutes les modifications apportées lors de l'exécution de la commande.
La fin d'une session (selon le logiciel) peut prendre un certain temps pour communiquer à SQL Server que la session a été terminée. Lorsque je me connectais à DB2 à partir de SQL Server à l'aide de serveurs liés, DB2 mettait en mémoire tampon la commande de fin et il fallait souvent jusqu'à une heure à DB2 pour réaliser que la session avait été terminée.
Pour déterminer dans quelle session vous exécutez, vous pouvez essayer:
select @@spid;
une fois que vous avez le spid (disons 86), vous pouvez ensuite émettre (selon si vous avez la permission de le faire)
kill 86;
mais comme le note Microsoft: met fin à un processus utilisateur basé sur l'ID de session ou l'unité de travail (UOW). Si l'ID de session ou l'UOW spécifié a beaucoup de travail à annuler, l'instruction KILL peut prendre un certain temps pour se terminer, en particulier lorsqu'elle implique l'annulation d'une longue transaction.