p_o_p_e_t wrote:
> On Dec 29 2007, 8:01 am, Thorak <diving...@[EMAIL PROTECTED]
> wrote:
>> Ok, I have spent the past 2 days researching this and cant seem to get
>> anywhere. System setup is:
>>
>> Win XP PRO sp2
>> PHP 5.2.5
>> Apache 2.2.6
>> Paradox 5 (I think)
>>
>> One machine has the paradox database on it (used by another program as
>> well). Another computer has PHP and Apache on it. Unfortunately I
>> don't have the option of putting it all on the same computer. I have
>> had a ridiculous amount of problems getting to this error... but
>> finally past all the other ones. I will refer to these as PHP machine
>> and Paradox Machine for ease.
>>
>> Now I know this isnt a PHP group, but most of these similar errors
>> seem to be posted in this section... so here goes:
>>
>> I keep getting the following error:
>>
>> Warning: odbc_connect() [function.odbc-connect]: SQL error:
>> [Microsoft]
>> [ODBC Paradox Driver] Could not open Paradox.net., SQL state S1000 in
>> SQLConnect.
>>
>> - I setup a test to see if this problem was PHP based or Network
>> based. Copied the whole paradox data dir onto the PHP machine as
>> trial. Pointed the ODBC connection to this version of the paradox DB
>> and everything works fine.... so it definately has something to do
>> with the network connection... but I don't know what else to try!
>>
>> - I have tried the instructions on the following
>> link:http://sup****t.microsoft.com/kb/142479
>>
>> - I have tried using BDE Admin on the PHP computer to edit the
>> IDAPI.Cfg and link through a mapped network drive to the paradox
>> machine - but cant as the PDXUSRS.NET file is in c:\ (cant share c:\
>> drive - therefore cant map). All this as per : several group
>> discussions I came accross. I thought about changing the location of
>> the .NET file on the paradox machine - but my admin wont let me.
>>
>> Any suggestions?
>
> You should modify the NET DIR of your ODBC datasource. NET DIR of your
> ODBC datasource should be pointed to the same location as the other
> applications. ODBC datasource NET DIR settings is located in
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\Your DSN\Engines\Paradox
> \ParadoxNetPath.
Thorak, let me set some groundwork for you ... and see if thereby I can
explain what's happening here. :-) (Trust me, I know where you're coming
from on this one!)
Paradox is, inherently, a fileserver-based database system which, like
(say...) dBase, was architected for either "a single microcomputer" or "at
best, an office file-sharing network." Now here we are, many years later,
putting the same architecture to work in a radically different
environment:
an Apache web-server. An "outward facing" system, thereby
very-intentionally isolated from any sort of "trust," very-intentionally
relegated to the role of "network outsider" precisely so that we can
protect the internal network from the very worst that a "133T L053R Script
Kiddie" might devise in his pre-pubescent brain to do. :-D
Paradox, being designed for a single-computer or for a trusted internal
network (in a world in which the notion of "permissions" was never
seriously im****tant because "the Internet" did not exist yet...) is
somewhat ill-prepared for what a system like Apache needs to do. It's
rather un-suited to the role that Apache needs to be in.
The Apache web-server, running as whatever heavily-restricted "non-user"
it
may have been very-intentionally relegated to, must be able to have "full
permission" to the directories in which the Paradox databases reside. And
it must ALSO have both permissions to and knowledge of the location of ...
the so-called "network control-file" (NET DIR), this being the file in
which
locking-related infomration must be stored. (After all, Apache might be
sharing this database with dozens of other workstation-users on the local
network.)
Apache, therefore, is rather DESIGNED to be "the most NON-trusted guy on
the
block," precisely because Apache is at the beck-and-call of the entire
Internet. And yet, Apache must be able to ... not only operate in, but
CO-OPERATE in, an architecture that was originally envisioned to be used
in
an isolated office network.
It can be done! And done well!! But you need to understand the
situation.
----
ChimneySweep(R): Fast(!) table repair at a click of the mouse!
http://www.sundialservices.com
|
