[Za-pm] Databases & Perl

[Ian Balchin]

Jonathan & Tielman, hi,

As I progress with my interim port to Paradox I note a small problem. Not 
that I might not find a way around it, but it justifies a pause.

The problem is that the Pdox normal field length max is 256 characters. 
There are 'memo' fields that will take as much as you like, but export from 
Memo fields and import into Memo fields (say from/as a delimited format) 
takes place at the 256 character level, or is even not supported - at least not 
without special code. ie you can write up several k of data but you are likely 
to get only 256 chars in or out.

If I was looking at one of the SQL databases, is this a likely scenario for 
them as well?

If you ask where does this extra data come from, then my Clue database 
has no restrictions whatseover on the field length (this was a major selling 
point 20+ years back for book dealers making catalogues as 256 chars or 
whatever is very restrictive in terms of book descriptions - titles can even be 
longer than that). Thus I have fields with perhaps a thousand characters that 
are likely to be severly truncated.

Sorry if this is a bit off topic, but it all boils down to perl in the end!

regards
Anne




On 13 May 2008 at 14:48, Jonathan McKeown wrote:

> On Tuesday 13 May 2008 12:38, Anne Wainwright wrote:
> > Hi,
> >
> > A ramble of a know nothing, for comment and suggestions.
> >
> > Bear in mind that apart from my dos database I am fairly competant with
> > Paradox. For the uninitiated, this Windows app was originally from Borland,
> > later from Corel, and provides a database with integrated design
> > environment where you can add your buttons and tables etc to a form and
> > then add code to those objects to make it go the way you want. Far more
> > powerful than Excel was. Design of forms and reports is a snap.
> [snip]
> > I see and note that Perl has many modules and features designed to enable
> > it to work with an sql type database. The questions in my mind revolve
> > around some complex applications that I have created in Paradox. Am I going
> > to have to create them with a much lower level language than I am used to?
> > Paradox's ObjectPal provides a fully integrated development environment
> > where you drag and drop and add some code to the objects already dragged,
> > sized, coloured, and dropped.
> 
> The problem you have with developing GUI applications is that producing a 
> graphical interface is complicated. It's easier if you have a development 
> environment that lets you drag and drop your components in the way that 
> Access or Paradox does.
> 
> > Further confusion because so much of what I read (well, scan) on sql
> > databases refers to their use for internet applications and how to view the
> > data through your browser.
> 
> Another way to develop an application which looks good and is easy to use with 
> a mouse is to make it a Web application. This is very popular because the 
> application now only needs a Web browser installed on the client rather than 
> the whole application, and using HTML as your output format offloads a lot of 
> the nonsense involved in managing the gory details of screen layout onto the 
> browser.
> 
> > Has Perl passed its sell-by date in this field?
> 
> Now that's almost a religious question. Perl has been around for 20 years and 
> for much of that time, it was King of the Web. It is still good at what it 
> does, and the libraries that are available from CPAN (including many web 
> tools) are still actively developed (apparently 25% of the 13,000+ modules on 
> CPAN have a most recent version upload date in the last 4 months, and half of 
> them have been updated in the last 17 months).
> 
> On the other hand, it's harder to learn than PHP (I would argue that once 
> you've learned Perl, it's easier to program well with than PHP - others would 
> disagree), and there seem to be fewer Perl programmers around, especially in 
> South Africa for some reason, to help you out.
> 
> > As you can see I am lost in the desert here. Any comments on how the ground
> > is laid out these days and which path I should take are most welcome.
> > Rather post to the list as my email client will handle these automagically
> > for me.
> 
> If I were in your shoes, I would probably take the web approach: it gives you 
> much more flexibility in the long run (can easily move from Windows to Linux 
> etc). Having decided that, I would probably look at web frameworks, such as 
> Catalyst for Perl (there are similar frameworks for other languages), which 
> make the whole process less painful (the buzzword to look out for is CRUD, 
> Create-Retrieve-Update-Delete, describing the four basic operations you need 
> on a database. Googling for CRUD database will get you some more 
> information).
> 
> Bear in mind another of Perl's strengths is the DBI database interaction 
> module. In PHP, if you write your application for MySQL and then change your 
> mind and decide to use a different database, you have to find and replace 
> every single mysql_**** function with the equivalents for the new database. 
> (This is starting to change - there is at least one database access layer 
> available now). In Perl, provided you've used DBI.pm, all you need to do is 
> change your connect statement. DBI provides a standard interface to your data 
> and automatically loads the right DBD (database-dependent) module for the 
> database you're connecting to.
> 
> Jonathan
> _______________________________________________
> Za-pm mailing list
> Za-pm at pm.org
> http://mail.pm.org/mailman/listinfo/za-pm

----
Anne Wainwright