Bonjour à tous

je programme en php et je me suis décidé à me mettre au vb net grâce à ce site pour créer quelques applications utilisable sans internet, rien de compliquer pour l'instant

J'ai réaliser un petit programme pour lire et remplir une base, c'est un programme d'inscription de membres créé sous Visual Studio

il fonctionne très bien en test , en le publiant avec fichier set up et tout, pas de problème  ça fonctionne sous mon ordi portable....

tout content j'ai voulu le faire fonctionner au boulot en l'installant sur une autre machine... là... ça ne fonctionne pas

Mes questions:

1) Dois je installer sql server aussi sur la machine du boulot pour le faire fonctionner?

2) Dans le cas ou je dois installer une base de donnée sur l'autre machine aussi, ne vaut mieux t il pas que je fasse mon programme en utilisant ACCESS comme base, vu que c'est un logiciel présent presque sur toutes les machines....?

3) Il y a t il moyen de publier le programme en incluant la base de données, de sorte que le programme soit utilisable sous toute machine sous windows?

Merci pour vos réponses et pistes de réponse

Veuillez m'excuser pour la longueur du message, j'ai voulu être claire....

David

1) Ça dépend de votre fournisseur de données ADO.NET. Si c'est SQL Server et qu'il doit être en local, oui.

Généralement, on arrive à cette "extrémité" sciemment :

C'est rare d'avoir besoin d'un gestionnaire de base de données par utilisateur et dans ce cas, SQL Server est clairement un mauvais choix.

En prenant ses précautions, il est facile de changer de fournisseur de données ADO.NET, même de manière "dynamique".

Pour installer SQL Server Express avec le MSI de votre application :

https://blogs.msdn.microsoft.com/user_ed/2012/12/09/how-to-embed-sql-server-express-in-an-application/

2) ACCESS sur presque sur toutes les machines ??? On ne vit pas dans les mêmes dimensions alors !!!

Non, ACCESS n'est clairement pas le "choix par défaut". Des fichiers textes simples comme fournisseurs de données, c'est largement plus pertinent. LINQ permet de faire toutes les manipulations de données simple dans l'application elle-même.

Si vos données commencent à gonfler, vous pouvez passer à un autre fournisseur de données sans la moindre modification dans votre code, seul le fichier de configuration devra être modifié.

3) Si, exactement comme un fichier annexe dans le MSI. Le gestionnaire de données lui-même peut aussi faire partie de l'installation, comme indiqué dans la réponse à la question 1). (via MSM, custom action + script console, mise à jour du MSI, etc...). Si vous utilisez des middleware comme Entity, ils se chargent généralement automatiquement de la création à la volée de bases de données vides.

Bonjour

Merci pour la réponse détaillée...

Alors je retiens que ACCESS n'est pas une bonne idée et que d’inclure mon SQL Server (embded) serait compliqué.

1) Mon application servira à rentrer les informations des visiteurs d'une petite manifestation sur une semaine... on risque d'avoir plus de 200 personnes (nom, prénom, adresse, téléphone, email, etc...), l'application servira à les répertorier, à les lister, à donner des statistiques de fréquentation par ville etc...

je peux faire ça avec une base de donnée fichier?

L'application sera installée sur deux machines au niveau de l’accueil secrétariat. Donc je prévois l'installation sur 2 postes au moins, sans connexion internet ... sinon j'aurais codé en PHP tout simplement.

2) Je bosse aussi sur une autre application qui sert à afficher des paroles de chansons. Il y en a à peu près 800 déja répertorié dans la base SQL SERVER. Meme problème, en publiant je n'ai pas d'affichage, ce qui est normal car je n'ai pas la base dans l'appli.

Pour ce deuxième cas vos mieux inclure la base par embed?

Cette appli sera distribuée gratuitement... ce sont des chansons libres de droits, genre cantique; avec parole et musique en mp3

Merci de prendre le temps de me conseiller

Blessings

>je peux faire ça avec une base de donnée fichier?

200 personnes, à l'aise Blaise.

1- Dans ce type de projet, on utilise généralement une architecture à 2 niveaux.

Un niveau local, avec des données en local

Un niveau "central", où les données local de chaque "terminal" sont "consolidées"/synchronisées avec la base "centrale".

Il existe pas mal de solutions "clé en main" pour ce type d'architecture (SQL Server + SQL Server CE, etc...).

Elles prennent en chargent pas mal de détails à la con comme la non répudiation, les règles business de merging, la gestion des règles de la loi RGPD, etc...)

Les données que vous collectez sont sujettes à l'application de la loi RGPD en Europe. Si vous êtes en Europe, implémenter complètement le RGPD, c'est vraiment pal mal de taf.

Mais techniquement, l'utilisation de simples fichiers texte pour 200 personnes, c'est largement faisable, même avec des vieux PC d'il y a 20 ans.

En plus, la fusion des données, c'est peanuts dans ce cas. (mais la gestion des règles RGPD, c'est une autre histoire, mais c'est plus règlementaire que technique).

>Pour ce deuxième cas vos mieux inclure la base par embed?

C'est à dire ?

Il faut voir les licences d'utilisation de vos sources de données.

Mais si vous programmez "correctement" vous pouvez facilement passer d'un fournisseur de données à un autre.

Si vous n'utilisez pas de fonctions évoluées des gestionnaires de données comme les rechercher "full text", gestion des coalescences, etc..., vous pouvez prendre tout type de fournisseurs de données, fichiers "plats" y compris.

L'avantage des fichiers plats, c'est que l'utilisateur final peut facilement ajouter/supprimer/modifier les données (le développeur aussi ;-) )

Vous pouvez aussi vous tourner vers des gestionnaires de données comme SQLite qui est spécialisé dans les bases de données "embarquées" avec un exécutable, etc...

Salutations

Vraiment un grand merci pour les conseils... c'est ce don j'avais besoin

Je vais tester les fichiers... il est temps de mettre mes mains dans le cambouis

j'ai essayé d'inclure Sql lite dans mon application... pour l'instant j'ai des erreurs mais ça ira... les recherches et le travail paie

Pour mon application de recueil de chants Sql lite semble très bien indiqué; mais je vais suivre vos conseils pour coder le mieux que je peux pour pouvoir utiliser n'importe quelle solution par la suite.

Je reste en .NET mais je vais par la suite faire tout ça en C# je pense.... 

je garde le sujet encore ouvert au cas où d'autres auraient d'autres idées

Blessings

David

Salutations bonjour

Je viens donner des nouvelles

ça se passe plutôt bien avec SQLite; rapide et soigné... mes 800 enregistrement passe comme une lettre à la poste.

J'ai eu un peu de mal au début avec le système de connexion, mais rien de bien méchant en réalité.... 

Merci pour le conseil sur l'écriture des codes de connexion, car maintenant je passe aisément d'une base à l'autre... j'utilise Sql Server pour exporter ou migrer mes bases vers Sqlite.

Concernant mon passage en C#, ça traîne un peu car c'est plus dure que ce que je pensais, même si que la structure ressemble beaucoup à PH avec les accolades et les pont virgules partout. En fait je veux me mettre au C# pour développer mon application pour les mobiles avec xamarins et C#..... histoire de faire d'une pierre 3 coups

Merci encore...  

Blessings

David

Salutations

Je fais ceci et ça a l'air de fonctionner...

ça tient la route?

Dim BDDPath$ = Path.GetTempPath & "\base_exemple.db"
        File.WriteAllBytes(BDDPath, My.Resources.truc)
        Dim strConnexion As New SQLiteConnection("Data Source=" & BDDPath)
        Dim myConnexion As SQLiteConnection = New SQLiteConnection(strConnexion)
            myConnexion.Open()
            Dim sql As String = "select ref,titre from table_choses;"
            Dim cmd As New SQLiteCommand(sql, myConnexion)
            Dim myreader As SQLiteDataReader = cmd.ExecuteReader()
            While myreader.Read()
              ********************
            End While
            myreader.Close()
            myConnexion.Close()

Pour la génération de chemin, utilisez plutôt Combine pour ne pas avoir de problème de compatibilité :

https://docs.microsoft.com/fr-fr/dotnet/api/system.io.path.combine?view=netframework-4.8

Pourquoi cloner la base dans un répertoire "TEMP" ???

Les DataReader, c'est caca, utilisez des DataSet+DataAdapter, bien plus simple et safe.

Utilisez les préceptes RAII au lieu des immondes "Open/close" en utilisant "Using":

https://docs.microsoft.com/fr-fr/dotnet/visual-basic/language-reference/statements/using-statement

Salutations

Merci à vous

Les Datareader c'est caca, c'est à dire?

Comment puis je utiliser combine dans mon cas précis?

Merci

David

>Les Datareader c'est caca, c'est à dire?

Parce que c'est très chiant à utiliser par rapport à des DataSet/DataAdapter qui font bien plus, bien plus simplement et de manière plus sûre.

Il y a au moins 10 ans d'écart entre ces 2 conceptions (10 ans en informatique, c'est une éternité).

Par exemple, pas besoin de boucle à la con avec des DataSet/DataAdapter, etc...

>Comment puis je utiliser combine dans mon cas précis?

Dim BDDPath$ = Path.Combine(Path.GetTempPath,"base_exemple.db")

Cela simplifie grandement les problèmes de portabilité, de "/" ou "\" terminal ou initial , etc... (et c'est surtout bien plus lisible (pour un œil averti)).