On 30 Oct 2012, at 12:00, Craig Chant wrote:

> "What was the reason for not using DBIC again?"
> The non-normalised DB with a  missing schema and the fact the data is spread 
> across two SQL servers on separate DSN's.

You didn't say anything there that didn't imply DBIC is fine.

The reason for not using DBIC again?

Also, your SQL abstraction has hilarious SQL injection holes - you do know 
about this, right?

> It's just before the return of the record set or count I was wondering if I 
> need to add '$sth->finish();' or '$dbh->disconnect();' - which I have in my 
> current (non-catalyst) app version of the class (module).

You're doing something wrong with DBI here!

> I also believe that DBIC gets all columns from all tables, which I don't 
> want, dunno, perhaps I'm missing something with DBIC, but I understand my 
> data the way I retrieve it and didn't think there was anything wrong with 
> using my SQL class, it has served me well for 10 years, and powers all my 
> current apps.

That's by default, and optional.

> One thing I have found already is the app doesn't seem to see real time SQL 
> updates even if I issue    $sth->finish(); &   $dbh->disconnect(); at the end 
> of my method.
> I make a manual change to SQL (switch the 'Locked' flag between 'yes' & 'no') 
> , refresh the app and it isn't registering the SQL change, so already it 
> seems something is being cached somewhere and I need to stop this, my apps 
> need to see DB changes instantly.

Again, you're doing something wrong or insane here - this is not normal, so you 
must be asking for it somehow.


List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Reply via email to