Fishy wrote:
Ah, your saying to use the DataAccessAdapterBase to create my own DataAccessAdapter to go against the Image Database. Correct?
I did not think of that. It does not seem like a simple task. How would the Adapter know how to translate Image datatypes correctly?
Creating a DataAccessAdapter would not be my choice. It adds a component with a much higher abstraction level to the solution. I noticed that most of the problems we are experiencing are coming from the high abstraction level components. Also, controlling concurrency, locking and performance with generic components will be hard.
On the other hand, when you are the only developer and you are not afraid of the abstraction of the generic dataaccessAdapter, it makes the actual migration to SqlServer much faster.
If you are willing to invest a little bit, you could also use some additional 3-party components to make things easier. As far as i know there are a number of vendors that have connectivity tools for the image database. An alternative approach can also be to actually persist some of the data to the Sql database and use the SqlServer functionallity to synchronize with image.
Follow this link for an example:
http://www.minisoft.com/pages/middleware/odbc32/pages/odbcar.htm