nous avons une grosse application access à migrer en sql server. Nous allons
donc passer en objets ADO pour gérer cette base de données.
Dans tout le code, nous utilisons les méthodes seek pour faire des
recherches rapides sur index.
Nous avons testé cette méthode avec accès à la base sql server. Nous
constatons que les méthodes seek ne fonctionnent avec un provider OLEDB.1.
On a essayé en natif, meme probleme.
Nous avons lu sur cetains forums que d'autres avaient également eu ce
probleme.
La seule solution pour l'instant consisterait à convertir tous les seek en
select where. Mais cette opération nous prendra des mois.
Qui a déjà été confronté à ce probleme? Quelle solution peut-etre envisagé?
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
jmn
La méthode seek n'est pas supportée par SQL server (même si elle existe dans le composant ADO pour être utilisée vers les SGBD qui la supporte).
Effectivement, la seule solution est de transformer les seek en 'select ... where ...' ou en find (au détail près que le find est mono champ/mono critères et que si l'on veut retrouver un find multi-critères il faut ecrire une fonction !).
Pour une conversion rapide sur des gros projets, une astuce peut être de créer une méta fonction (metaseek) qui, en fonction du jeu d'enregistrement et de l'index sélectionné pourra générer, en fonction des cas, un find ou un select...(notez que sous ADO vous pouvez toujours enregistrer un nom dans la proriété index du recordset !). Par exemple : function MetaSeek(byval Action$,Ta as adodb.recordset, byref data1,optional data2 = null, optional data3=null, optional data4=null) as boolean ....(vous compléterez facilement le corps de la procédure) select case action case "FIND" .. find case "SEEK" ... select end select end function Le composant ADOX permet de retrouver les noms des index et les champs qui les composent.
Cela oblige bien sûr à remplacer les seek du code, mais une fois la fonction au point, le travail peut être facilement automatisé ou confié à un débutant...
En ce qui me concerne, j'ai écris des 'méta-fonctions' pour toutes les méthodes de gestion de base de données (depuis VB3 !), ce qui me permet de produire sans trop de difficultés des versions Access, SQL Server, Oracle ou dBase sans changer le code maitre de l'application. De toutes façons, si vous souhaitez conserver la possiblité d'attaquer une base Access il n'y a pas vraiment d'alternative.
Bonne chance.
La méthode seek n'est pas supportée par SQL server (même si elle existe dans
le composant ADO pour être utilisée vers les SGBD qui la supporte).
Effectivement, la seule solution est de transformer les seek en 'select ...
where ...' ou en find (au détail près que le find est mono champ/mono
critères et que si l'on veut retrouver un find multi-critères il faut ecrire
une fonction !).
Pour une conversion rapide sur des gros projets, une astuce peut être de
créer une méta fonction (metaseek) qui, en fonction du jeu d'enregistrement
et de l'index sélectionné pourra générer, en fonction des cas, un find ou un
select...(notez que sous ADO vous pouvez toujours enregistrer un nom dans la
proriété index du recordset !). Par exemple :
function MetaSeek(byval Action$,Ta as adodb.recordset, byref data1,optional
data2 = null, optional data3=null, optional data4=null) as boolean
....(vous compléterez facilement le corps de la procédure)
select case action
case "FIND"
.. find
case "SEEK"
... select
end select
end function
Le composant ADOX permet de retrouver les noms des index et les champs qui
les composent.
Cela oblige bien sûr à remplacer les seek du code, mais une fois la fonction
au point, le travail peut être facilement automatisé ou confié à un
débutant...
En ce qui me concerne, j'ai écris des 'méta-fonctions' pour toutes les
méthodes de gestion de base de données (depuis VB3 !), ce qui me permet de
produire sans trop de difficultés des versions Access, SQL Server, Oracle ou
dBase sans changer le code maitre de l'application.
De toutes façons, si vous souhaitez conserver la possiblité d'attaquer une
base Access il n'y a pas vraiment d'alternative.
La méthode seek n'est pas supportée par SQL server (même si elle existe dans le composant ADO pour être utilisée vers les SGBD qui la supporte).
Effectivement, la seule solution est de transformer les seek en 'select ... where ...' ou en find (au détail près que le find est mono champ/mono critères et que si l'on veut retrouver un find multi-critères il faut ecrire une fonction !).
Pour une conversion rapide sur des gros projets, une astuce peut être de créer une méta fonction (metaseek) qui, en fonction du jeu d'enregistrement et de l'index sélectionné pourra générer, en fonction des cas, un find ou un select...(notez que sous ADO vous pouvez toujours enregistrer un nom dans la proriété index du recordset !). Par exemple : function MetaSeek(byval Action$,Ta as adodb.recordset, byref data1,optional data2 = null, optional data3=null, optional data4=null) as boolean ....(vous compléterez facilement le corps de la procédure) select case action case "FIND" .. find case "SEEK" ... select end select end function Le composant ADOX permet de retrouver les noms des index et les champs qui les composent.
Cela oblige bien sûr à remplacer les seek du code, mais une fois la fonction au point, le travail peut être facilement automatisé ou confié à un débutant...
En ce qui me concerne, j'ai écris des 'méta-fonctions' pour toutes les méthodes de gestion de base de données (depuis VB3 !), ce qui me permet de produire sans trop de difficultés des versions Access, SQL Server, Oracle ou dBase sans changer le code maitre de l'application. De toutes façons, si vous souhaitez conserver la possiblité d'attaquer une base Access il n'y a pas vraiment d'alternative.
