EasyWeather V7.8 avec Base de données Access

[bel84]

Bonjour,

Je me suis enfin offert une station PCE-FWS 20 avec le logiciel EasyWeather Version 7.8.
Dans cette version, l'historique est archivé dans une base de données access (.mdb) qui est installées dans le dossier
"User, Public, EasyWheaser". Cette base contient 2 tables que j'ouvre avec access, sans login ni mot de passe.
Les données sont enregistrées dans la table "Records".
Depuis une semaine je fouille pour trouver la configuration de GW, mais rien ne fonctionne.
Je choisi le plugin ODBC,(capture1)
Dans les options, le règle les capteurs, le driver , et le dossier de la DB (capture2), puis j'ajoute la table Records (capture3).
Lorsque je valide, j'ai un message d'erreur que je ne comprends pas (capture4).

Si quelqu'un peux m'aider, j'en serais ravi.
Merci d'avance.

[paaubert]

Salut,
je ne pense pas que ça fonctionne comme ça, as-tu essayer de passer par un serveur, genre wampserver ?
http://www.wampserver.com/

En tout cas pour une base de données mysql il faut passer par un serveur, mais je n'ai jamais essayé avec une bd access

A+

[bel84]

merci paaubert.
Non je n'ai pas essayé de créer un serveur sur ma machine. Mais ça m’embête un peu de créer un serveur local pour réussir à uploader des données sur un serveur web distant.
Je vais donc continuer à fouiller...

[bpellissier]

Peu etre un peux tard mais si c'est toujours d'actualité j'ai une solution.
Tu connais access ? Macro etc..

Bruno

[bel84]

Bonsoir,

Effectivement, je maîtrise un peu MsAccess et VBA, même si cela fait plusieurs années que je n'ai plus pratiqué.

J'ai tenté de créer un formulaire avec un évènement timer pour exporter la table Records qui contient les données de ma station météo vers un fichier texte au format csv que je pourrait utiliser avec GraphWeather, mais j'ai un problème:
En manuel, l'export se passe bien, mais pas en automatique. J'obtiens le message d'erreur:
" Erreur d'exécution '3625':
La spécification de fichier texte Exportation-EasyWeather n'exite pas....".

Je joins une copie d’écran avec les différentes fenêtres.

Capture.jpg

Là je suis pommé.

Si vous avez une idée, je suis preneur.
Merci d'avance.

[jturlier]

Bonjour,
le format date/heure des fichiers/base de données .mdb d'EW est de type datetime SQL, il n'est pas supporté par GW, en effet il ne s'agit pas d'un type date formatée %d%m%Y... (bien qu'il apparaisse en clair dans MSaccess) qui ne s'applique qu'à un champ text ou bigint. Il y a déjà eu pas mal de discussions sur ce sujet : le résultat est qu'il ne fonctionne pas avec GW.
Jean

[bpellissier]

Bonsoir,
Effectivement c est la solution, un programme access qui tourne non stop, avec une macro ou vb
Qui lance un export en csv
Par contre il faut faire une requete intermediaire pour mettre les champs "propre" pour gw.
Il faut extraire la date/heure en format texte ( extrac chaine pour access ) pour remplir le champ proprement.

Telecharge mon fichier, pas pour l'utiliser mais pour piquer les idees ( il est fait pour cumulus et esayweather, mais le principe reste le même )

Après utilise l import csv de gw, j ai testé, ca marche

Bruno

[bel84]

Merci pour les réponses.

Bruno, je veux bien télécharger ton exemple, mais ou????

Et pour l'erreur d'export Access, une idée?

[bpellissier]

Sur mon site ( signature) bouton "Les plus" il y deux prg access.
Je fait joujou avec access donc a prendre avec precaution !

Pour le 3625 c est un probleme d import, moi j importe tjrs dans une table sans rien changer( brut quoi) tout les champs texte a 255 caracteres.
Et apres je fait une requete pour transformer les donnees.

[jturlier]

bonsoir,
n'est-il pas possible avec Msaccess de créer une View comme
create view matableconvertie (DatePart("yyyy",colonnedate)||DatePart("mm",colonnedate)||DatePart("d",colonnedate)||DatePart("h",colonnedate)||DatePart("MM",colonnedate),* ) as select * from matable

J'ai trouvé ça :

Access does support the data definition SQL create view.

However, this statement will NOT work in the query builder unless you turn on ANSI sql in your application. I strongly recommend that you don't do this unless it's absolutely necessary. The reason for this is that if you have an existing application, then a good deal of your SQL statements will start to break, as engaging this feature in access also changes the legal wildcard characters that will work in your your SQL. (you have to use % sign in place of * for wild cards in your sql for example).

So, access does support the create view table.

However keep in mind that views created in access are identical to what we call a select statement that you build in the query builder. Therefore for all purpose you might just as well create a select statement in the query builder.

In code, you can't use DAO and sql "create view" UNLESS YOU turn on the sql ANSI options. You CAN use the ADO object model regardless if you turn on ansi 92 sql or not.

If you are just playing around are wanting to learn some SQL statements, then you can go into the tools and options and engage the sql ANSI option to allow the use of create view in the query builder.

Office button->access options->object designers->
SQL server compatible syntax (ANSI 92)
[x] - This database
[ ] - Default for new databases

As mentioned I want to stress to not use this option for existing applications, as it'll cause many things to break.

The other way is to simply use the built in ADO Connection MS access. You can hit ctrl-g and bring up the debug window ( our command prompt line ) – yes, access does have a command prompt!!

You can then type in:
CODE
currentproject.Connection.Execute "create view qtest3 (Firstname, Lastname) as

select firstname,lastName from tblMycust"

(above should be typed on one line)

Just keep in mind that terminology might also be confusing you here. While access and jet DDL commands does support the use of create view, that resulting view will appear as a standard select statement in the query builder AFTER you execute the create view. In other words after you execute the create view command, if you go into the query tab in the NAV pane, you'll see that the view name you just created appears as an standard SQL select statement. I should also point out that this point in time the reason why we don't call it a view in the query builder, is because the query builder also loves you to build delete statements and other different kinds of SQL statements that are not necessarily just select statements. So to really clear up this issue, in the query builder if you choose to build a select statement, that is that SQL server people would call a view. so part of this confusion centers around the fact that we access and JET users don't calll a select statement a view, but but that's the general term for SQL server people.

For all intents and purposes creating an view in access is simply the equivalent of creating and select statement in the query builder. For this reason most of us who rarely if ever used to create view commands and simply fire up the query builder and build our select statement that way..

However if you're building an application that must run with SQL server or MS access at the same time, then starting out your project with ANSI SQL turned on, and using the ADO object model in place of DAO is most certainly a viable concept and approach to developing a SQL server application in access that works for both jet and SQL server at the same time.

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com

Edited by: AlbertKallal on Fri Jan 15 9:12:57 EST 2010.

Voir la syntaxe pour la récupération du mois et des minutes (je ne suis pas utilisateur d'Access)
Ensuite on peut utiliser cette View comme entrée de GW. Cela évite toutes les opérations de création d'un fichier .csv

Bonne soirée

Jean