Hi all: Well, JDBC is great to connect to any database that has a JDBC driver. Changing databases is made easy by changing the driver - we know that. But, considering that not all databases support auto-increment for primary keys, or they don't all support all possible joints, or whatever... How do you implement your code to make it portable across several databases? 1) First, do you save your SQL statements somewhere in a config file (or XML)? 2) Do you implement your business logic that returns a recordset in a separate class for each database you plan to support, so that switching to a different database is just a matter of implementing a new class without changing the code in your app? 3) Is it where the DAO design pattern comes in? I was facing that problem when I was developing an app that connected at first to MS Access, then I switched to MySQL (or was it another one? don't remember) that did not support auto-increment. I had to recode my app. Any thought? Thanks, Francois
in n-tier theory, you have a seperate tier for database access which you would code for a particular target database. to use the app with another database, you would code another database access layer. you shouldn't have any SQL outside the database or database access layer. You would have to decide on a strategy for passing the data from the data services layer up to the business layer - either xml, or CachecRowSets or UDTs or whatever. What's DAO? Surely you don't mean the MS Data Access Objects?
I have seen things you people would not believe, attack ships on fire off the shoulder of Orion, c-beams sparkling in the dark near the Tennhauser Gate. All these moments will be lost in time, like tears in the rain.