dBASE/Python Developer

Kosmik said:
Are the developers actually coding in dbase or just reading? I remember back in 2006 or so, we used to read from a dbaseIII database but all the work would be done rather in sql etc. Even back then it was considered a old product, certainly time to consider modernising, lack of dev support least concerns.
Click to expand...

It would appear some are still coding, be damned if I actually found a developer :D
 
schuits said:
I did some work for a company a few months ago. They were using dBaseIV, access and a long forgotten programming language....bleh. I of course used SQLLite and C#.NET to do my work, then just dumped the results into Dbase.
Click to expand...

Hmm, my cogs are turning.

dBase powers our admin program that we use to capture our data. The data from here gets added to a database that we then pull use to create flat files that we upload to our server. These flat files though are customized to our clients needs. Would something like this be possible with your above method?
 
Last edited:
o_O Certainly brings back memories; wrote a lot of code in dBase and Clipper in the late 80s / early 90s.
 
OMSea said:
You could write a lot of code in 2018 too ;)
Click to expand...
Lol... must say I'm surprised to see someone still using dBase today; I considered it pretty much dead toward the end of 90s, even Microsoft couldn't keep it alive with FoxPro..
 
There is Python library to read dbf files, not sure if indexing works.
I'm assuming that you need more done than simply read database.
 
[)roi(] said:
Lol... must say I'm surprised to see someone still using dBase today; I considered it pretty much dead toward the end of 90s, even Microsoft couldn't keep it alive with FoxPro..
Click to expand...

I don't think it will ever quite stick. I want to get the ball rolling on moving us to Python ASAP.
 
aleksandar said:
There is Python library to read dbf files, not sure if indexing works.
I'm assuming that you need more done than simply read database.
Click to expand...

We need to allow for the customization we do. When clients move to us, we need to match their current data feed to allow for an easy switch over. Our customers spend huge amounts on building internal systems, for us to put a spanner in the works never sits well.
 
[)roi(] said:
o_O Certainly brings back memories; wrote a lot of code in dBase and Clipper in the late 80s / early 90s.
Click to expand...
Yeah, I cut my teeth on Clipper/DBase in the 90's.

But seriously, anybody still using DBase like that needs their heads read. There is no reason good enough to justify not having exported it into MySQL or something and re-writing it over the last 20 years.
 
garp said:
Yeah, I cut my teeth on Clipper/DBase in the 90's.

But seriously, anybody still using DBase like that needs their heads read. There is no reason good enough to justify not having exported it into MySQL or something and re-writing it over the last 20 years.
Click to expand...

This is why I have started the process of finding a dev who not only recalls dBase, but will also be able to help with the transition to Python.
 
garp said:
It literally is from the 90's. I seriously remember that page (or one virtually identical) from about 1998. It hasn't changed.
Click to expand...

My favorite part is the "Sign my guestbook" button!
 
OMSea said:
Our data currently gets pushed to our SQL databases on our server, we would link into those...
Click to expand...

Why not cut out the custom Dbase layer and implement some kind of integration software to convert client feeds to the data format of your choice?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X