Yes, it definately is possible, and not that hard. You can use Access to set up your tables, and ultimately, an .mdb file will house all your data. Even though the data is stored in the .mdb file, you don't need Access to read and write to the data.
You can use Visual Basic 6.0 to create an executable that refers to the tables in the .mdb file. The VB front-end is similar to Access, in that it allows you to create forms that will link to a record source set in the objects properties.
There's a few really neat things about VB 6.0 that you dcan't do in Access. You drop-combo, listboxes, etc. have lots more properties to play with. The rules of form construction are also more leniant. It is a breeze to have a VB form covered with listboxes and dropcombos all linked to different data sources. There's lots more, but I could go on and on about the pluses of building your db using an executable instead of an mdb. Of course, I forgot the most obvious, and thats that you can take the database anywhere, you just need the .mdb file to hold the tables, and an .exe to hold the forms and code.
One downside to creating dbs in VB is the lack of query help. In order to query in VB, you will need to have that query already built in the .mdb file. That doesn't seem like a big problem, but, that means no dynamic criteria. The SQL in any query that is in the .mdb file can not change. So if you have a query that sets a criteria from a textbox on a form, you can no put that in the .mdb file. It won't pick up the value from the textbox.
The only way to achieve a dynamic query in access in to either hard code it in as code with variables getting their value from the .exe's forms, or set the rowsource property of the object you wish to populate with the appropriate SQL.
HTH,
