Collaboration : Cisco Unified Intelligent Contact Management Enterprise

Problème d'ordre de DateTime des résultats de requête SQL lors de la mise à niveau de SQL 6.5 vers la version 7.0

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit pourquoi la commande de résultat de requête SQL par date-heure pour le Route_Call_Detail ou la table de Termination_Call_Detail entre les versions 6.5 et 7.0 de Microsoft SQL est différente et fournit un workaround dans un environnement de l'Intelligent Contact Management de Cisco (missile aux performances améliorées).

Conditions préalables

Conditions requises

Cisco recommande de posséder des connaissances sur ces sujets :

  • Missile aux performances améliorées de Cisco

  • Microsoft SQL

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Missile aux performances améliorées de Cisco

  • Microsoft SQL Server version 6.5 et 7.0

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

Quand vous améliorez à la version 4.6.2 ou ultérieures missile aux performances améliorées de Cisco, le Microsoft SQL Server version 6.5 est amélioré à la version 7. Après que la mise à jour, exécutant la requête SQL contre le Route_Call_Detail ou la table de Termination_Call_Detail sur le système ICM qui exécute la version 7 SQL renvoie des résultats différents de la version 6.5 SQL. Voir la cette requête SQL :

Figure 1 : Requête de Microsoft SQL Server

datetime-order-sql-1.gif

Quand vous comparez les résultats d'exécuter la même requête SQL sur le vieux système ICM qui exécute la version 6.5 SQL, le contenu est identique. Cependant, les nouveaux résultats ne sont pas dans la commande date-heure croissante comme les résultats d'origine. Avant que la mise à jour, cette requête ait renvoyé des données dans la commande date-heure. Puisque la mise à jour, des données n'est pas retournée dans la commande date-heure, comme affiché ici.

Figure 2 : Résultats de requête SQL dans la commande date-heure

/image/gif/paws/52760/datetime-order-sql-2.gif

Solution

Après que vous amélioriez de la version 6.5 SQL à la version 7.0, les résultats des requêtes choisies terminées contre le Route_Call_Detail ou le Termination_Call_Detail ne sont plus dans la commande date-heure. Une commande par clause doit être insérée afin d'obtenir les résultats date-heure. C'est une question parce que la commande par clause peut ajouter le temps système significatif au Route_Call_Detail et aux requêtes de Termination_Call_Detail, qui peuvent produire les positionnements très grands de résultat.

La commande par clé primaire dans la version 6.5 de serveur SQL est provenue le vieux système de Sybase où Microsoft SQL a commencé. Microsoft a serré la conformité à la norme SQL dans la version 7.0 de serveur SQL qui ne garantit pas une commande sans commande par clause dans la requête SQL. C'est une base de données relationnelle pas un fichier physique séquentiel. Il n'y a aucun ordre assumé dans une base de données relationnelle comme il y a dans un fichier physique séquentiel. Par conséquent, il est nécessaire d'employer une commande par clause pour établir un ordre dans le résultat.

Remarque: Ce n'est pas Cisco émettent. C'est une question de norme de Microsoft SQL Server.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 52760