Applications exportable & Gestion Congés

T'en passer ;)
ce n'est pas indispensable au design
MySql n'a pas ca non plus

Citation:

---

Envoyé par olibara

ce n'est pas indispensable au design

---

euh, t'as déjà essayé de définir des associations manuellement avec EF ? C'est bien galère :?
Si le SGBD les supporte et que le provider ADO.NET les gère correctement, c'est tout de suite beaucoup plus facile ;)

Citation:

---

Envoyé par olibara

MySql n'a pas ca non plus

---

Si, mais en fait ça dépend du moteur que tu utilises... c'est supporté pour les tables InnoDB, pas pour MyISAM

Citation:

---

Envoyé par tomlev

euh, t'as déjà essayé de définir des associations manuellement avec EF ? C'est bien gai

---

Ah oui c'est vrai on est en EF :roll:

Citation:

---

Si, mais en fait ça dépend du moteur que tu utilises... c'est supporté pour les tables InnoDB, pas pour MyISAM

---

Tu a raison mais quand j'utilise MySql, c'est justement pour rester basic, je desactive toujours InnoDB et j'apprécie beaucoup avoir toute mes table dans des fichier distinct.
Et pour des bases plus "costaudes" j'utilise MS SQL

N.B. : Je viens de commencer a utilise EF et je trouve en définitive asser confortable d'avoir une app mixte
1- Des acces "traditionnels" pour certaine manipulation de reporting ou autre
2- EF pour s'ouvrir l'esprit ;) mais ma premiere impression c'est que c'est quand meme un gros Bateau :?:roll:

Citation:

---

Envoyé par olibara

N.B. : Je viens de commencer a utilise EF et je trouve en définitive asser confortable d'avoir une app mixte
1- Des acces "traditionnels" pour certaine manipulation de reporting ou autre
2- EF pour s'ouvrir l'esprit ;) mais ma premiere impression c'est que c'est quand meme un gros Bateau :?:roll:

---

Tout à fait d'accord, pour ce qui est reporting (et d'une manière générale, des grosses requêtes complexes et dynamiques) il vaut mieux rester en SQL. Le moteur de conversion Linq => SQL se débrouille bien pour des petites requêtes, mais quand il y a plein de jointures et de sous-requêtes, c'est pas très optimisé...

Citation:

---

Envoyé par tomlev

Elle est dans le mauvais sens ta foreign key... c'est employes qui doit référencer role, et non l'inverse :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

CREATE TABLE [ROLE] ( [ROL_ID] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, [ROL_NOM] NVARCHAR(30) NOT NULL );   CREATE TABLE [EMPLOYES] ( [EMP_ID] INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, [EMP_NOM] NVARCHAR(30) NOT NULL, [EMP_PRE] NVARCHAR(30) NOT NULL, [EMP_ROL] INT NOT NULL, FOREIGN KEY (EMP_ROL) REFERENCES ROLE(ROL_ID) );

---

Je sais pas si c'est pour ça qu'il y a une erreur, mais on sait jamais ;)

EDIT: en fait si, je suis sûr que c'est pour ça... ta clé étrangère faisait référence à un champ qui n'était pas la clé primaire de l'autre table, et ça correspond bien à ce que disait le message d'erreur

---

Quand je voie l'erreur que j'avais fait, ca parait tout de suite logique ^^
Jl'avais bien appliqué quand je l'ai gérer sous SQLserver mais pas SQLlite ><
Merci en tout cas

Citation:

---

Envoyé par tomlev

Si c'est multi-utilisateur et multi-poste, il faut que la base de données soit commune à tout le monde, donc qu'elle soit installée sur un serveur accessible à tous les clients. Ca exclut d'office les base de données fichier comme SQLite ou SQL Server CE...

Pour SQL Server, a priori il n'y a pas besoin d'installer quoi que ce soit sur les clients : le provider ADO.NET pour SQL Server est déjà inclus dans le .NET Framework

---

Quel BDD pourrait être multi-utilisateur ? Si je mets la BDD sur un serveur et les applications sur les différents postes, cela ne marcherai pas avec SQLite ?

Citation:

---

Envoyé par flo_053

Quel BDD pourrait être multi-utilisateur ?

---

N'importe quelle base de données serveur (Oracle, SQL Server, MySQL, PostgreSQL, etc), mais pas une base fichier (SQL Server Compact, SQLite, Access...)

Citation:

---

Envoyé par flo_053

Si je mets la BDD sur un serveur et les applications sur les différents postes, cela ne marcherai pas avec SQLite ?

---

Non, SQLite est une BDD fichier, il n'y a pas de processus d'écoute pour accepter des connexions à distance

Citation:

---

Envoyé par tomlev

N'importe quelle base de données serveur (Oracle, SQL Server, MySQL, PostgreSQL, etc), mais pas une base fichier (SQL Server Compact, SQLite, Access...)


Non, SQLite est une BDD fichier, il n'y a pas de processus d'écoute pour accepter des connexions à distance

---

Donc BDD sans instalation et multi-utilisateur c'est impossible ?

Citation:

---

Envoyé par flo_053

Donc BDD sans instalation et multi-utilisateur c'est impossible ?

---

A ma connaissance, oui. Une BDD multi-utilisateur requiert un serveur, et qui dit serveur dit installation, configuration, etc

Citation:

---

Envoyé par tomlev

A ma connaissance, oui. Une BDD multi-utilisateur requiert un serveur, et qui dit serveur dit installation, configuration, etc

---

J'ai opter pour SQL Express, j'ai reussi à le mettre sur le server, me reste plus qu'à créer une installation automatique ainsi qu'un script de création de la base/table.
Par contre pour récuperer les données je sèche :o
Par exemple en cas de crash du serveur, tous les fichier sont sauvegardés sur un DD externe, mais il faut faire les réinstall -> d'où les install' auto que j'essaie de créer mais comment faire pour récuperer les données de la BDD et les réinsérer ?

Citation:

---

Envoyé par flo_053

Par exemple en cas de crash du serveur, tous les fichier sont sauvegardés sur un DD externe, mais il faut faire les réinstall -> d'où les install' auto que j'essaie de créer mais comment faire pour récuperer les données de la BDD et les réinsérer ?

---

Euh... alors là je serais bien incapable de te répondre, je connais pas grand chose à SQL Server ;)

Pose plutôt la question dans le forum SQL Server