[Techtalk] Leaving Win$ for linux.

Fri Jan 4 09:25:51 UTC 2008

Thanks, Conor & Andre,

I get around to looking at both those option this year soonest.

I have to query 'reporting tools' as I am not sure on the meanings of
database terminology.

In Paradox terms there are 'reports' which can be viewed on screen 
but which are primarily intended to be printed out as they are 
formatted displays of data selected and arranged to preselected 
criteria. ie. I have a report to output books for the university by 
department, subject-course, year, etc.

Also there are 'forms' which are display windows mainly for data 
entry and manipulation. These are created by the user placing tables,
fields, buttons, etc. and the object-pal code can be attached to these
objects to modify the default behaviour allowing colouring, calculations,
data entry, lookups, etc. etc. ad infinitum. My most complex form is for
automated purchasing of used texts, select the books one by one, select a
condition, and internal calculations total what to pay for the pile of
books, record all transaction data, etc. A 'report' run at the end of the
day outputs a daily transaction summary for record purposes.

'Reporting tools' in my searches seems to mean the sort of tool 
useful to the sysadmin to check the condition of his database, no of
records, tables, users connected, etc. Am I wrong there?

Open Road sounds like what Paradox provides to develop 'forms' - ie 
an application that uses the database proper. Must look at.

Happy New Year
Anne
Your 17 December 2007 email from Conor Daly  said thus::

> On Mon, Dec 17, 2007 at 12:20:44PM +0200 or so it is rumoured hereabouts, 
> Ian Balchin thought:
> > 
> > On the database side I now realise that I must concentrate on finding 
> > some sort of front end to any on the database offerings that at my 
> > level will probably all be found more than competant. So interbase as 
> > noted, firebird seems good too - and I found a 'datapump' that will 
> > take my pdox tables and structures and recreate them in Firebird.  
> > 
> > I don't see an all in one equivalent to Paradox with its all in one 
> > approach of database, GUI front for creation of tables, reports, 
> > forms, etc. plus an integrated object-based language, the terminology 
> > on most of these database sites is beyond me in most cases and maybe 
> > one has to go to the more commercial side of linux to find a 
> > solution.  
> 
> There is one business class database which has been released under GPL
> over the last few years.  Ingres (http://www.ingres.com).  It's stable,
> robust, powerful and we have used it for years.  Our use of it is almost
> entirely via C programs with sql embedded though we have in recent times
> started coding php interfaces to the data.  It supports proper locking,
> atomic transactions and all the multi-user / client-server goodness.
> 
> Ingres does come with reporting tools, a gui interface (though this may be
> a windows only tool) and some other serious toolsets.  There is also a gui
> development environment (OpenRoad) which has been around since before
> visual basic and such.  This is probably the fastest development platform
> for ingres at the moment.  It is currently a commercial product with the
> developer license costing around EUR1000 and runtime licenses costing
> around EUR300 but it is intended that it will be released under the GPL
> next year.
> 
> If you're going to have to embark on a porting project, I would recommend
> ingres as a possible back-end and OpenRoad might be worth considering for
> the front-end (if you don't mind the proprietary licensing).
> 
> For our setup, we insist on having tech support contracts in place.  These
> are not terribly cheap (but certainly not expensive compared with license
> costs for the likes of oracle or MS Sql server).  I don't think I'm
> allowed to divulge how much we pay for support but I'm well happy with the
> support we get.  On the rare occasions that we have had issues, ingres
> have been on the case from the moment we have made contact and have stayed
> with us until it has been resolved.  For a smaller operation such as you
> describe, I wouldn't expect their support costs to be as high as we pay
> but I don't know how they scale.  Of course, you can go unsupported and
> rely on the community and the, pretty good, ingres documentation.
> 
> > Anne
> > Your 30 October 2007 email from Rudy Zijlstra  said thus::
> > 
> > > Anne,
> > > 
> > > Not an easy one...
> > > 
> > > Ian Balchin wrote:
> > > >
> > > > Over the years I have played with linux a lot. It is on my laptop, I 
> > > > write perl scripts in it to massage text databases, and use it for 
> > > > quite a bit of personal email, browsing, etc. nothing too serious I 
> > > > guess.
> > > 
> > > > The second hurdle is that I have a lot of database stuff developed 
> > > > over the years in Paradox, hours of my coding is sitting there. I 
> > > > know that there are solid databases available, but what about the 
> > > > front end, I rarely see mention of those, and Paradox provides a 
> > > > complete development environment with its own language ObjectPal. I 
> > > > don't want to have to start from ground zero all over again coding 
> > > > access in perl. I have staff who need something similar to what they 
> > > > are used to. Again, comments from those who have had experience with 
> > > > Paradox development would be welcomed. Making forms, reports, 
> > > > queries, Pdox made this as easy as it could be for a computer 
> > > > literate user who did not  necessarily need to be a computer fundi 
> > > > with $ prompts shining out of his eyes..
> > > >
> > > > These two hurdles prevent a complete move to linux. the first may be 
> > > > a matter of compromise, but the second is a matter of pure business. 
> > > > No Paradox, no business.
> 
> The bottom line here is what matters.  If you don't want to spend hours
> re-coding your paradox stuff, you might consider buying in the coder to do
> the port.  OTOH, if you're already au-fait with database interaction in
> perl, you should be pretty much ready for any sort of embedded sql
> programming.  On that basis, it might be worth your while doing the port
> to something like C or perl or whatever and using standard ANSI SQL to
> remain future-proof for if / when your next choice of database bites the
> dust.  Choosing OpenRoad (as I suggested above) does push you towards
> ingres vendor lock-in and so might not the your best move.  However, it
> does appear to be a solid dev platform and might just be the way to go.
> 
> I'm happy to converse further on the subject if you wish, on or off
> list...
> 
> Regards,
> 
> Conor
> -- 
> Conor Daly <conor.daly at cod.homelinux.org>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GCS/G/S/O d+(-) s:+ a+ C++(+) UL++++ US++ P>++ L+++>++++ E--- W++ !N
> PS+ PE Y+ PGP? tv(-) b+++(+) G e+++(*) h-- r+++ z++++ 
> ------END GEEK CODE BLOCK------
> http://www.geekcode.com/ http://www.ebb.org/ungeek/
> _______________________________________________
> Techtalk mailing list
> Techtalk at linuxchix.org
> http://mailman.linuxchix.org/mailman/listinfo/techtalk
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.503 / Virus Database: 269.17.4/1187 - Release Date: 12/16/2007 11:36 AM
> 

--
Fables Bookshop (Proprietor: Ian Balchin) Est. 1990
119 High Street, Grahamstown, 6139, South Africa.
Tel/Fax: Shop  +27-(0)46-636-1525
Tel: Home office:  +27-(0)46-622-2474
cell: 
Skype: fablesbooks    (subject to my being at the computer station).
http://www.fables.co.za/
subscribe to our email africana catalogue:
http://lists.imaginet.co.za/mailman/listinfo/fables-list
email: aesop at fables.co.za
ici on parle francais
Founder member Southern African Book Dealers Association