View Full Version : dbase library

10-21-2004, 01:23 AM
I would like to write a function that converts dbf files to mysql, on the server side, so the user can upload the database file (and not require a client-side conversion program).

According to the documentation, the php installation needs --enable-dbase for these functions to work, which it is not.

I apologize for my lack of php knowledge (i'm learning it now), but is this something i can enable myself, or is it only a compile time option? If compile time, can i recompile the php for my VPS?

10-21-2004, 02:11 AM
I don't have experience with dbase files exactly, however....

--enable-dbase is a compile time option, so yes you would need to recompile php yourself.
As to whether you can do it, well, in theory we have the tools to do so, but I'm not sure if we have the permissions.

Can't you export the database in another format (comma delimited or summat) and use that? Thats what I usually do.

10-21-2004, 02:22 AM
That's what I was thinking. If i cannot do it on the server, then that will be how i accomplish this.

The desktop application is a third party app that uses dbf files. I want to make it as simple as possible for the end user, such that they upload the file(s), and don't have to run a conversion program. Also, i would prefer not to maintain a client-side utility.
It needs to be "updated" or uploaded around 4 times a day. So i can't just use one of those conversion tools that are available because it has to be one-click automated (for end users), and those tools require 99% manual intervention.

So, i'm just hoping it is possible to just hide it all on the server.

10-21-2004, 08:58 AM
Yes, I understand the problem. Normally I have the same situation with MS Access files, in which case there is button they click, which runs a VBA macro which creates a text file. The user then has to upload the file through a form on the website which then imports it into MySQL.

It is two steps (export and upload) but so far they have managed it. The only problems have arisen when they changed the query on which the export was based. But a good whipping soon sorted that out...

10-21-2004, 12:29 PM
I didn't want to have to do it that way. Because if i'm already coding to read from a db and then sync with the tables (yes, sync, not just insert), then i might as well do it all at one place.

But, i know you are the guru of westhost hacks, so if that's how you do it, then I guess i'll give in and do it that way too. ;-)

Have you ever asked westhost for dbase, or have they explicitly denied it?

10-22-2004, 01:11 AM
FYI, i asked support about this, and they said i would have to recompile php. They said this was outside of their support offerings, they did not discourage me from doing so.

So, if anyone else has (re)compiled php and is willing to give me a quick tutorial with regards to westhost, I would greatly appreciate it.

From what I can see, php source code is not there, so I would have to get the latest (or get the 4.3.0 version) and untar it and build it myself.
I noticed the dbase.php in the /usr/lib/php/DB, and perhaps that is compilable. I will see what I can find and if no one else answers, i'll post my findings.


10-22-2004, 02:12 AM
If you are comfortable with Perl, that may be an alternative as well. I seem to remember they have a number of dbase modules, you may even find a ready built program to do what you want.

10-22-2004, 03:00 PM
Not a bad idea. I seem to be opening a can of worms... i have php source, but i now need lex/flex, bison, etc, etc. and i can't do RPMs, so i'd have to compile/install those manually, and the chain of dependencies may never end.

So, if i can write it in perl, perhaps i can kick it off from a web page and if not, then a cron job.


10-24-2004, 02:38 AM
Good luck!