kirchaj
Posts: 215
|
| Posted: 04/26/2012, 2:21 PM |
|
I am having some issues creating a new connection on my Windows 7 laptop. I am in the process of moving everything over to it (a big pain) and I am running into a problem described here
http://forums.yessoftware.com/posts.php?post_id=107670
ERROR [IM014] [Microsoft][ODBC Driver Manager]The specified DSN contains an architecture mismatch between the Driver and Application
but its the first time I have used the system and codecharge on it. I am using a 64 bit OS and 64bit odbc postgres driver.
The odbc driver tests and connects fine. Any ideas before I contact support??
Thanks
TK
|
 |
 |
DataDoIT
|
| Posted: 04/26/2012, 6:28 PM |
|
Are you running 64-bit version of Postgres?
|
|
|
|
kirchaj
Posts: 215
|
| Posted: 04/27/2012, 5:44 AM |
|
Hey DataDoIT
I should have put that info in before. I am using the Postgres 64 odbc driver.
Kinda at a loss.
|
|
|
|
DataDoIT
|
| Posted: 04/27/2012, 6:50 AM |
|
You're using the 64-bit ODBC "driver", but are you also attempting to
connect with that 64-bit driver to a 64-bit version of Postgres? They
MUST match architecture.
|
|
|
|
kirchaj
Posts: 215
|
| Posted: 04/27/2012, 11:24 AM |
|
Well you may be onto something. I am trying to connect my Windows 7 machine (64bit) with the Postgres odbc client (64 bit) to my Postgres Database running on RHEL 5 (64 bit) Postgres v. 8.1 database. The odbc client can connect when I test it. It is only in CCS that there is a problem.
|
|
|
|
DataDoIT
|
| Posted: 04/27/2012, 1:19 PM |
|
Okay, there are many things going on here. Forgive me if all this
sounds patronizing - I'm working on a limited set of info given.
You know that CCS has a design mode and a server mode. Then, CCS has
publishing locations (Server), for which the Common.php file will be
adjusted according to that server location.
-If- you're connecting successfully from your Win7 desktop to the RHEL
server via ODBC (remember, ODBC runs in a port in the TCP/IP networking
layer), then that means you have the ODBC port (typically 5432) for
Postgres open on your RHEL server to accept connections outside of
itself (localhost or 127.0.0.1). That's a -BAD- security practice.
When you're developing in CCS, you'll always want to mimic your
production environment as much as possible. In your case, you'll want
to develop on Win7 64 bit, with Postgres for Windows 64-bit, along with
that Postgres for Windows 64-bit ODBC driver. You'll also want to run
it all on Apache 64-bit for Windows. Then when developing and testing,
you'll publish to your own web server running directly on your Win7 machine.
When you set your production server options in CCS (via FTP), the
connections that are made from the PHP application to the Postgres
database will actually use the native Postgres socket and port for
connecting (the php_pgsql package), NOT ODBC as you know of it in
Winderz, and certainly NOT the ODBC driver that's installed on your Win7
machine. RHEL knows nothing of your Win7 machine at that point. You
can manipulate your RHEL to use native ODBC connections instead, but
that will require the installation of something like the unix_odbc package.
1. Set up your Win7 machine, or development environment, to match that
of your production server. That means installing Apache, PHP, Postgres,
and the Postgres ODBC driver.
2. Don't allow unsecured remote connections to Postgres on your RHEL
machine. Only allow localhost or 127.0.0.1. If your needs dictate
otherwise, rethink those needs. You can always use SSH/SCP/SFTP for
making remote connections when needed.
3. If you're really really bored, set up a test environment on your Win7
machine that matches exactly the production environment. That means
installing RHEL on your Win7 machine. You can accomplish that via
Oracle's VirtualBox. If you're in a workgroup of other developers, then
you certainly should have a test machine already configured.
|
|
|
|
kirchaj
Posts: 215
|
| Posted: 04/27/2012, 2:20 PM |
|
Hey DataDoIT,
Not patronizing at all. I really appreciate your time. I obviously still have a lot to learn :)
Some of this setup is from years ago when I did not have a clue about postgres, databases, etc. Maybe still don't lol. I do have the database connections limited to my building network segment. But you are right I should change my setup and eliminate that hole.
I get what you are saying about developing locally and then publishing to the server. That will take a little time and work but I can get that setup next. Once that is setup I can change the connection security issue for good.
DataDoIT, thanks for taking the time to respond. It is greatly appreciated. If I had your explanation a couple years ago you would have saved me a large amount of time.
TK
|
|
|
|
kirchaj
Posts: 215
|
| Posted: 04/30/2012, 8:11 AM |
|
DataDoIT,
Mind if I pick your brain a bit? So how do you keep track of changes you make to the local database and the roll that out into the production database? I am pretty simple minded and am totally a one man show. A one man show with not enough hands lol
TK
|
|
|
|
DataDoIT
|
| Posted: 04/30/2012, 10:51 AM |
|
Use Navicat (http://www.navicat.com/).
It's to database management what CCS is to web application development.
|
|
|
|
|
