jdtoronto
|
| Posted: 08/20/2003, 11:46 AM |
|
Hi folks,
This is more a pre-sales thing. When I tried CCS a year or so back I was annoyed that I had to have a local database for development and a remote db for production. As I recall the local db could only be connected to using ODBC.
Of course this was a major pain for me, so I decided not to proceed with the product purchase. Now I am thinking again that I need some speed-up process for development. Problem is that my production and development systems all use the same db servers - so I want to be able to specify the same server for both development and production. I have a direct 3mbps connection form the house here to my datacenter only a few kilometres away, we only work with MySQL and we are not able to use ODBC at all.
Have the requirements of CCS changed? Is there a workaround??
John
|
|
|
 |
glerma
|
| Posted: 08/20/2003, 3:23 PM |
|
That's never been true for CCS. You can still have a remote database (i.e. on some other PC or server) for your development.
The key to doing that is by using ODBC. ODBC is not a major pain to use. It can be used to connect to virtually ANY Database out there. You don't need to have the database on your PC. By setting up an ODBC Data Source, you can easily connect to your DB of choice. With regard to MySQL, there is a special version of ODBC called MyODBC that you can download from MySQL's website that will allow you to use ODBC on your PC. I know because, I've used it. Go check it out.
Link:
http://www.mysql.com/downloads/api-myodbc-3.51.html
Incidentally, I have BOTH my dev and prod databases on the same Instance with no problems!
If I have mis-understood your question, please let me know.
|
|
|
|
jdtoronto
|
| Posted: 08/20/2003, 4:34 PM |
|
I have a number of MySQL servers running. We find that using ODBC connections tends to introduce problems - almost invariably instability and performance issues - when we mix them with direct connections. So we took out ODBC and all our applications now use direct connections, or more correctly, we use SSH secure connections for everything. Then we have the security problems noted in a number of places that apply to ODBC.
If we can use direct connections on the production side, why cant we use them on the development side?
Hence you see my problem.
...john
|
|
|
|
glerma
|
| Posted: 08/20/2003, 8:41 PM |
|
Well. I'm not sure what else to say about that. You are pretty much stuck with ODBC for design time database connections.
The main differences with the production connection managers with the design-time connection managers is that they are specific to the Programming Language that you are developing in. So it is technically not feasable to create a design-time CM to handle all of the different Database Call Interfaces. In addition ODBC uses ANSI SQL to perform the operations, which allows for standardized calls to any database that it connects to. ODBC is good in the sense that it provides the drivers for a wide variety of DBs.
I would probably say that the security precautions that you spoke about are valid however the RAD capabilities of CCS far out-weigh the issues of security. Especially in a development environment You will have to make that determination yourself. I would also say that having BOTH development and production DB's on the same server is sort of a development no-no. I think your first priority is to try to have a seperate "less-secure" development environment to work with. However, I can understand that some people have to make do with what they have.
Regards,
george
|
|
|
|
RonB
|
| Posted: 08/21/2003, 2:13 AM |
|
Have you thought of setting up a mysql slave/mirror to wich you would be allowed to connect. It wouldn't even have to be a monster machine if a small development team is the only thing connecting to it. That way the main servers will not be bothered by odbc connections and the development team could still use odbc to connect to the slave/mirror. I have found it can be a pain to keep my local database in sync with the main database but that's not because of the data, more because of the table structure. If you set up a slave/mirror you could backup the main database at night and update the slave/mirror with that info.
Ron
|
|
|
|
|
