Discussion :

[noftal]

Bonjour,

Comme j'expliquais dans un précédent topic, je suis en train de tester mon appli sur un autre ordinateur que celui que j'utilise pour le développement afin de vérifier sa robustesse.

J'observe sur ce 2ème ordi une erreur "SQL Logic error or missing database ambiguous column name ..." lorsque je fais quelques gestes alors que, avec le même enchainement sur l'ordi de développement, je n'ai pas cette erreur.

Pour info :
- ordi de développement : tourne sous Win7 X64
- ordi de test : tourne sous XP 32 bits
- mon appli utilise SQLite comme SGBD

Je me souviens que SQLite a une DLL pour le 32bits et une autre pour le 64 bits. est-ce que cela peut être la cause ?
Cependant, dans mon répertoire contenant l'exécutable, j'ai bien 2 sous répertoire, x64 et x86 contenant tous deux un fichier SQLite.Interop.dll différent
En revanche, le fichier system.data.SQlite.dll est unique et se trouve dans le même répertoire que le .exe

[wallace1]

Il faut vraiment considérer qu'à partir du moment que ton architecture varie entre un PC et un autre qu'il faille prévoir au niveau de ton programme une implémentation afin de te retrouver sur un environnement identique.

Tu dis avoir 2 répertoires (x64 et x86) au même niveau que ton exe mais est-ce que cela est automatique la création de ces dossiers ? et es-tu certains que ton appli pointe automatiquement vers le bon fichier "SQLite.Interop.dll" selon l'architecture du PC sur lequel s'exécute ton programme ?

Dans un 1er temps : ton projet a-t-il été configuré en AnyCPU CPUtarget ? si tu dev sous VS2012 as-tu bien pensés à décocher la case "preffered32Bits" ?

Tu devrais envisager ceci :

1- renommer chaque version du fichier "SQLite.Interop.dll" en :

- SQLite.Interop64.dll (la version x64 Bits)
- SQLite.Interop86.dll (la version x32 Bits)

2- ajouter chaque version de fichier dans les resources de ton projet

3- ajouter une routine qui permettrait d'identifier l'architecture (32 ou 64) de l'OS sur lequel s'exécute ton programme afin d'extraire depuis les resources le bon fichier "SQLite.Interop.dll" à côté de ton programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
       Private Shared Function OSIs64bit() As Boolean
            Try
                If (Environment.GetEnvironmentVariable("ProgramFiles(x86)") <> "") Then
                    Return True
                End If
            Catch ex As Exception
            End Try
            Return False
        End Function

En gros dans ta Sub Main tu pourrais ajouter ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Imports System.Threading
Imports System.IO
 
Friend Class Program
    <STAThread()>
    Public Shared Sub Main(Args$())
        Application.EnableVisualStyles()
        Application.SetCompatibleTextRenderingDefault(False)
        Dim instanceCountOne As Boolean = False
        Using mtex As Mutex = New Mutex(True, Application.ProductName, instanceCountOne)
            If instanceCountOne Then
                If OSIs64bit()
                    ExtractFileFromResource(Application.StartupPath & "\SQLite.Interop.dll", My.Resources.SQLite_Interop64_dll)
                Else
                    ExtractFileFromResource(Application.StartupPath & "\SQLite.Interop.dll", My.Resources.SQLite_Interop86_dll)
                End If
                Application.Run(New Frm_Main)
                mtex.ReleaseMutex()
            End If
        End Using
    End Sub
End Class
 
  Private Shared Sub ExtractFileFromResource(FilePath As String, ResName As Byte())
        If Not File.Exists(FilePath) Then
            System.IO.File.WriteAllBytes(FilePath, ResName)
        End If
    End Sub
 
       Private Shared Function OSIs64bit() As Boolean
            Try
                If (Environment.GetEnvironmentVariable("ProgramFiles(x86)") <> "") Then
                    Return True
                End If
            Catch ex As Exception
            End Try
            Return False
        End Function

Pour le coup tu peux également embarquer le fichier "system.data.SQlite.dll" et surtout ne pas oublier de l'extraire également !


A+

[wallace1]

Et sinon Noftal accessoirement cela réponds-il à ta question :

http://www.developpez.net/forums/d13...r/#post7586312

PS : je te demande car j'ai édité le post.

???

[noftal]

Tu dis avoir 2 répertoires (x64 et x86) au même niveau que ton exe mais est-ce que cela est automatique la création de ces dossiers ? et es-tu certains que ton appli pointe automatiquement vers le bon fichier "SQLite.Interop.dll" selon l'architecture du PC sur lequel s'exécute ton programme ?

A priori oui puisque l'architecture des fichiers en aval de \debug a été construite automatiquement par VS2010. Les répertoires x54 et x86 sont en aval de \debug et contiennent le même nom de fichier (mais pas le même fichier vu la taille différente de chacun). Je pense donc que l'appli pointe spontanément vers la bonne DLL en fonction de sa configuration. Qu'en penses-tu ?

Dans un 1er temps : ton projet a-t-il été configuré en AnyCPU CPUtarget ? si tu dev sous VS2012 as-tu bien pensés à décocher la case "preffered32Bits" ?

Etant sous VS2010 Ultimate je ne pense pas être concerné par la 2ème remarque. Sinon, oui, j'ai bien configuré en Any CPU mon projet

Pour la suite de ton post, je note l'astuce, mais si comme je le crois, VS2010 a construit un .exe qui va chercher tout seul soit dans x64 soit dans x86 la bonne DLL, je suppose que je n'ai pas à appliquer cette astuce. Qu'en penses-tu ?

Nota 1 : il faudra que je revienne vers toi à propos de "SetCompatibleTextRenderingDefault(False)" car elle cause une erreur chez moi. Pour l'instant, j'ai temporisé la question mais il faudra que j'y revienne. Enfin... c'est hors sujet.

Nota 2 : hier soir, de retour chez moi, j'ai copié mon appli (répertoire Debug) sur un 3ème ordi, perso cette fois, qui est clairement sous XP 32bits. Et là, pas de pb, je n'ai pas l'erreur qui est à l'origine de ce topic. Ce qui a tendance à confirmer mon hypothèse au sujet de l'automaticité de la redirection vers la bonne DLL, mais m'éloigne de la résolution de mon pb sur le 2ème ordi. Le but est, rappelons-le, de rendre mon appli insensible à l'ordi qui l'utilise. Le 2ème ordi est mon ordi pro sur lequel je ne suis pas admin donc le risque est que je trouve pas la solution car je ne maîtrise pas le degré de verrouillage que les informaticiens ont installé dessus.

[noftal]

J'avais laissé ce pb de côté quelques jours.
Puis ne trouvant pas d'explication, j'ai recopié ma bdD sur le 2ème ordi ce qui a résolu mon pb.
Bizarre, j'étais persuadé d'avoir pourtant copié ma BdD en même temps que les fichiers de l'appli.
Enfin,bref, c'est résolu.
toutefois, dans la même veine, je découvre que les DateTimePicker n'ont pas le même comportement sur les 2 ordinateurs.
Sur le premier : lorsque je clique sur l'en-tête du calendrier, cela transforme le calendrier en un "monthcalendar" (on ne voit que les mois de l'année en cours pour changer d'année plus rapidement).
Sur le 2ème : un même clic sur l'en-tête du calendrier ouvre un contextmenustrip avec les 12 mois de l'année.
A quoi est due cette différence de comportement ?