>This isn't a complete solution, but should help you get started. Ok. Let's see ... >1. First you need establish the database requirements. e.g. exactly what do you need to store, search, retrieve from your DB. How big are the images, how many, etc. I need to store sound files (wav, ...) with a date and time associated to every piece of data that represent 1 seconde of sound. The user can then search for a sound that have been recorded at a specific time. The program records continuously ... so I have a very large quantity of informations. >2. With that in hand, select a database engine. There are many, each has its own strengths, weaknesses and costs. Oracle and SQL server are enterprise databases. They are beefy and very capabley (expensive). Access is good for smaller or simpliler applications. May others also exist. I'm thinking about SQL servers. It sounds that it is more portable and robust. And once you know how it works, you have no problem switching to another one. QUESTION: Are these free? or do I have to by something? >3. Create the actual database schema (you don't need to populate it, just define it). Ok. >4. Finally ready to start designing/coding the app. At this point you can select accessing technologies. The main ones available are ODBC, DAO, ADO. ADO is the current favorite. I read a little about these technologies. I am more thinking about using ODBC. It sounds that I is faster than DAO (if I don't use Access database). Also, my database will be on a remote computer. I read that ODBC is more efficient in this case. >If this is a significant application, you may want to consult a DB expert to help you design your database and select a db engine. This really is a significant application. I am used to get things done by reading, asking questions, prototyping, ... Do you think that these are things we can't learn on the fly ? >Hope this helps, >Bill This helped a lot. Thank you very much. Where there is a WISH, there is a WILL.