What level of detail are you importing into ESdat?  We are successfully using ESdat to import soil testpit logs, though do find importing wells and detailed rock bore logs a little more complicated, and haven't fully resolved our import methods for those logs.

Hey guys,

 I assume the translation is for more than one Gint db? If it was only a single DB - i'd just migrate the Gint file via the usual ESdat excel import sheets, as there is a bit of setup time involved. Seeing as gint.gpj files are just access DB's anyway - rename one and you can then open with ESdat anyways

 We've set up a semi automated process to take old Winlog and Gint files and import into ESdat quite successfully. We used an intermdiate Access database with append queries that map the GINT tables to the appropriate ESdat tables.Linked tables in this db are used to point at ESdat and GINT respectively - so the links can be pointed to different DBS as required. Also lookup tables that map code lists in one database to another are handy- eg your lith codes listed in Gint db's may be different to those needed by ESdat.

Issues/ Steps that need dealing with-

1) You are assuming that you are always dealing with the same Gint datamodel (ie all built from same gint template database) - It doesnt matter if tables are sometimes empty so lobg as the structure doesnt change.

2) That the Lith codes are pretty consistant from a lookup list -if staff have been using them willi nilli it can be a pain. It was easier to fill in the lith description and leave the lith code blank -which allows us to view the historical data

 3) Watch out for allowable blank fields in Gint -have found a few of these in our gint dbs. The ESdat model Does not allow them and it can throw errors when trying to append the records- This sort of expression in a calculated Access field will get you around it IIf(Len([Method])=0,Null,[Method]) - I dont know how prevalent this is in Gint templates but it was set this way for ours.