No, the ODBC driver is read-only. You can use Import or File I/O.

Erika, are you saying that Sesames ODBC functionality is limited to other programs being able to read Sesames data only and that Sesame is not capable of issuing ODBC commands ? What alternatives do we have to be able to at least read Access database fields ?

Thanks Erika.

Since we are limited to working with an Access database it looks like the old Export/Import routine for us on a daily basis now !
Have you encountered this scenario much before - wanting to import regularly from an Access database (and I mean several times a day to make sure we're working in Sesame with current data) ?

Do you have any suggestions to facilitate a "single button" approach from within Sesame itself to perform the export routine within Access and Import into Sesame ? Things like only importing changed data not the whole exported file again? ie. reducing what is imported as much as how often the import is done. We work in a window of about 3-6 months of "active" data but the database goes back to the start of the business many years ago ! Only rarely do we require access to the actual jobs noted in the Access db after a year (these are separate files that the database refers to and are archived out after 13 months).

We have set up the importing already and have the required fields mapped but reducing this to a simple function that a user can perform would be important to avoid costly mistakes or delays in working with the right data. New jobs (around 8-15 a day) are added and are actively updated in both the Access db and Sesame db significantly for at least a 3-4 week period then it dies back to almost nothing.

Since the Sesame db is a tracking database that tracks whats in the Access db, timely information is vital !
Over time, the Access db will be done away with but we cannot do this for the foreseeable future at least.

Absolutely !

The Access db contains information about building plans, quantities of materials, etc. It is also part of a franchise and we do not have direct access to their programmers and for what we are working towards, shouldn't need to.

The Sesame db is intended to track the whereabouts of any plan we have received, both within the current premises, and other locations round the country and oversea's and to show what stage of completion they are at. This is something that the Access db simply does not do. It only records Job Details and doesn't "track" where they are both location or stage of processing-wise.

The "updating" within the Access db is firstly to log the job in, then to do with the quantities of materials as they are imported from a sub-program a few days later, then modified if necessary before being provided to the client. (Job is logged in, then worked on using a separate program AND separate database, then that result is exported from the sub-program and imported back into the Access db for corrections and production of the final list for the client).

The Access database (unfortunately ?) is a legacy program that is still at the core of the business and auto-generates the Job Number which then needs to be imported into Sesame so that tracking of plan stages, which person, and which location, can begin, using a common number.

There are a few items of data to be imported along with the all-important Job Number, such as Merchant Name, Builders Name, Address of Building to be constructed, Name of Job and Merchants Request Number. Theres a few other fields as well. Because the Access database is what produces the Materials List, any changes to say spelling of the Merchants Name or changing the name of the job must be done in Access so the printed/emailed/faxed list back to the client contains the most relevant data. Thats a given.

Since we do not have write access to Access, we're looking at an Import both on a regular basis (say every hour?) and an ad-hoc when we know there have been changes to the Access db. We may structure our work a bit more for the changes being made to the Access database which is NOT updated every hour at present. There may be several Access db updates as a job, or 2 or 3, with changes is worked on, then nothing for an hour or two... or three

Hopefully this clarifies why we have some constraints re Access and Sesame.

We're using Sesame v1.1.5 and "looking" at going to v2 but would like to prove to the business' owner that purchasing Sesame was the right decision before he has to fork out more dosh ! This will be his first on-site Sesame application.

The Access db format is '97 which we very rarely get to alter. The original db's were provided on CD and unless specifically directed we are not permitted to change anything to do with them. We only have Office, with Access, on 1 PC in the business there is so little requirement for us to change anything in Access !

Thanks Bob. Sounds very promising. Working on it.....

On a side-note, I still run Q&A v4 myself and am interested in your A97 / Q&A routines to see how its done. I can't ever see myself giving up QnA somehow...

Quick glance of long Access details ...... initial thought....
Depending on your environment, usage, and timing, timing may be a critical factor.

Add a boolean field for flaggins Export status.
Use ImmediateChange Event on selected fields to set a flag for Export. 
Now you can use the Export flag for the import.  Schedule the export routine to run hourly/daily, etc., but it will only run completely if any Export Flags are set.  Program to exit if no records found in Access.

Make an Access routine to capture  a result set o be exported, create export file from result set, reset the Export flags on those record s. 

Do not just Export records if flag is set, and then mark as exported, because a record could become marked to export before it actually happened, If that happened, you would be marking it as done when it actually was not exported.  The timing may be tight.

Import the data to Sesame.

Finally, make sure the Sesame elements holding the imported data are ReadOnly to prevent changes that did not happen in Access.  I make my ReadOnly elements with rounded corners where possible.  just a reminder to the users, they cannot change here.

Hope this made some sense.

If you have no functionality with the Access database, can you use that as a backend to a new front end copy of Access where you can create the functionality you need to program, export, etc.? 

The same thing as if you had split the database initially with a backend of data and a front end of queries, forms, macros, reports, etc.