Salut,
J'ai un répertoire avec plein de fichiers "*.meu" (on va voir les vaches ?)
Après potassage des bignious en hexa, il s'avère que c'est du dBase 3.
 
Si je renomme les fichiers en *.dbf et que je les interroge via MSJET, aucun souci, ça marche plutôt très bien.
 
Seul problème...
 
-> Ce sont les fichiers d'une application de caisse. Donc on imagine que ça peut rapidement devenir très volumineux, puisque c'est plusieurs lignes par chaque ligne de ticket de caisse...
-> Ce logiciel de casse se basant sur une base dBase 3, on imagine rapidement que c'est un vieux truc MSDOS (dBase 4 est sorti en... 1985). Du coup, l'appli tourne sur du matos d'époque (enfin... pas tout à fait non plus quand même ) En gros, j'ai des fichiers de plusieurs centaines de méga, sur des disques de 2 Go à tout péter, tournant sous Windows 98 avec 32 Mo de RAM (des super bêtes de course quoi).
 
Mon appli (en C#, genre déjà rien qu'en la démarrant je fout le PC à genoux) doit quotidiennement lire ces fichiers et envoyer des stats sur les ventes via HTTPS sur un serveur.
 
Seule couille dans le potage, MSJET plante lorsque je tente de lire un fichier directement "*.meu". Sur un forum j'ai trouvé une réponse consistant à faire un DSN par fichier, sans plus d'info sur si ça marche ou non, et surtout... moi je dois faire des jointures et tout ça, donc c'est mal barré si je dois les faire à la main en mémoire en C#...
 
Et vu le caractère musée du précambrien des machines sur lesquelle ça tourne, je me vois pas recopier l'intégralité des fichiers avant de les interroger, à tout le coup ça va durer des heures et planter par manque d'espace disque.
 
Donc, la question est : y'a moyen de moyenner pour ouvrir un fichier autre que DBF avec MSJET moyennant bidouille moyenne ?
 
Me suis paluché toute la BDR, modifié les assocs entre le drivers et les extensions de fichier, mais cacahuète, ça change rien.

Salut,
(je connais rien en c#, pas grand chose en db)
Faut voir la fonction qui sert a ouvrir le fichier, peut etre qu'il y a des options pour indiquer de quel type est le fichier, independemment de son extension.
Quel est le bout de code qui te sert a ouvrir le fichier?

Non, c'est juste un appel à MSJET via ODBC (DSN-less).
 
Voici la chaîne de connection :
 
OdbcConnection cnx = new OdbcConnection(@"CollatingSequence=ASCII;PageTimeout=5;UserCommitSync=Yes;MaxScanRows=8;DefaultDir=" + Application.StartupPath + @"\temp;DriverId=21;DBQ=" + Application.StartupPath + @"\temp;Deleted=0;Statistics=0;FIL=dBase III;UID=admin;Driver={Microsoft dBase Driver (*.dbf)};MaxBufferSize=2048;Threads=3;SafeTransactions=0" );
 
Sauf qu'au lieu comme pour SQL Server par exemple, de spécifier un serveur et un catalogue, ou comme Access, spécifier un fichier, ici on sécifie un répertoire, et tous les fichiers DBF du répertoire sont vus comme des tables (portant le même nom que le fichier).
Pas mal foutu d'ailleurs, puisque malgré la structure archaïque de la chose, on peut faire des requêtes aussi complexes qu'avec Access ou SQL Server.
Le "*.bdf", c'est juste dans le libellé du drivers.
Si je le change, ça marche pas, puisqu'il ne trouve pas le drivers. Et dans la BDR, sous les clés qui correspondent à ce libellé, y'a une entrée "FileExt" avec "*.dbf,*.idx,*.mdx" (ou un truc du genre, ce qui correspond aux fichiers de tables, d'index et de procédures stockées) et si je mets "*.meu" à la place, peau de cacahuète, ça ne change rien.

As tu le source de l'appli de caisse? ca serait super bien de voir comment elle fait elle pour ecrire dans du .meu
 
sinon dans
http://msdn.microsoft.com/library/ [...] driver.asp
partie "select directory", il est dit que l'on peut ne pas specifier le repertoire par defaut mais que l'on peut a la place indiquer le nom de la classe par son chemin (exemple:SELECT * FROM C:\MYDIR\EMP)
Est ce que cela pourrait faire l'affaire?

Ben mon souci, c'est pas le répertoire, mais le nom des fichiers...
 
Sinon, ben nan, pas moyen d'avoir le code source. De toute façon, à mon avis c'est des drivers 8 bits pour Cobol ou une connerie du genre... L'appli elle a été créée au moment des 286 avec MSDOS 2.0, et elle ne semble pas avoir beaucoup évolué depuis
 
Y'a qu'à voir la raction de l'éditeur quand on lui a annoncé qu'on allait imposer aux magasins de passer sous Windows XP... "Windows XP ? C'est quoi ? C'est après Windows 3.1 ?". Genre le mec il hiberne au fond de sa cave depuis 15 ans, et je crois pas qu'il soit au courant que maintenant on peut utiliser des fichiers avec des noms longs.

Dans "SELECT * FROM C:\MYDIR\EMP", EMP c'est le nom de la table donc du fichier!
N'y a t il que les fichier .meu, pas d'autres types de fichier dans le repertoire?

oui, sauf qu'il ne vois pas les fichier autres que *.DBF
 
si je fais cette requête sur un répertoire contenant les fichiers *.MEU, ça plante car in ne troupe pas le fichier.
si je fais :
 
select * from c:\winmeu\articl.meu
 
idem, table introuvable.

En fait les appli de caisse tourne en meme temps c'est cela, donc renommer le fichier n'est pas possible?
Dans ce cas si ton appli se mettait en marche apres la fin de la journée, renommer les fichiers en .dbf, transfert les données et renomme ensuite en .meu?
Ca serait d'ailleurs plus securisé car comme ca les tables n'evolueront plus entre deux requetes?

ben déjà oui , l'appli pourrait tourner en même temps. ceci dit, y'a de grandes chances qu'elles fassent un lock sur le fichier, donc c'est pas un problème si je dois leur faire arrêter l'appli (c'est juste pour faire des stats en fin de mois, ils peuvent attendre la fermeture le soir pour faire ces stats).
mon vrai souci, c'est que les fichiers sont très volumineux, notamment pour les machines archaïques que c'est. et donc recopier les fichiers prends un temps pas possible, et risque de planter par manque de place. et je ne veux pas les renommer : si l'appli se vautre, ils n'ont plus de caisse... et va expliquer à une caissière de renommer un fichier sur son disque dur toi
 
m'enfin bon, à priori, ça va être un faux problème. pour la nouvelle version d'une appli qui va tourner sur le PC de caisse, la centrale exige qu'ils passent tous sous XP Pro, du coup ils vont devoir abandonner leur 486

La version actuelle des appli de caisse va t elle tourner sous XP parce que si c'est du DOS actuellement ca se peut que non?
Dans ce cas que devient ton probleme?

chais pas, il va y avoir une nouvelle version, après c'est à l'éditeur de se démerder pour que ça marche. la centrale a exigé l'OS aussi auprès de l'éditeur.
 
et pour certains clients, qui sont déjà sous XP, à priori, il n'y a pas de problème hormis pour la lecture du code barre -ils doivent le taper à la main- (en fait, tant que tu touches pas aux interruptions matériel, à priori tu peux faire tourner n'importe quel programme 16/8 bits sous Windows XP)