Re: DBI seems to randomly die

I think you should instead create a normal table and use $RemoteAddr as an attribute. Table records are made to be easily created/updated/deleted, while databases aren't. If you want to clear a table use 'TRUNCATE' command, instead of dropping the whole table.

Anyway, the problem could also because of the invalid character contained in $RemoteAddr (which I assume containing ip address that contains dots) when dropping tables in 'drop table ${Database}.conv_${RemoteAddr}'

-cheepy-

Comment on Re: DBI seems to randomly die

Replies are listed 'Best First'.
Re^2: DBI seems to randomly die by FitTrend (Pilgrim) on Jun 07, 2006 at 14:21 UTC
Also good suggestions. However, I cannot truncate the table because of how the application works. Basically I create the merge based on a date range and their is 1 table per day. So 50% of the time, i have a completely different list of tables to merge. As for the IP Address, I'm aware that the dots are an issue so they are changed to underscores before being used in the table name. I'm also trying to avoid changing table structure or references to it since each table can become quite large (100MB+ a day) depending on the end-user's environment. This would make for a messy migration. Also, I want to stick with what the MySQL consultant recommended based on this architecture. I do want to point out that since DBI 1.48, this problem is less frequent then prior to that version. Scanning the changelog didn't really point to anything in particular that I could say has fixed my specific issue. /- M a r c -/	[reply]

Replies are listed 'Best First'.

Re^2: DBI seems to randomly die
by FitTrend (Pilgrim) on Jun 07, 2006 at 14:21 UTC

Also good suggestions. However, I cannot truncate the table because of how the application works. Basically I create the merge based on a date range and their is 1 table per day. So 50% of the time, i have a completely different list of tables to merge.

As for the IP Address, I'm aware that the dots are an issue so they are changed to underscores before being used in the table name. I'm also trying to avoid changing table structure or references to it since each table can become quite large (100MB+ a day) depending on the end-user's environment. This would make for a messy migration. Also, I want to stick with what the MySQL consultant recommended based on this architecture.

I do want to point out that since DBI 1.48, this problem is less frequent then prior to that version. Scanning the changelog didn't really point to anything in particular that I could say has fixed my specific issue.

/- M a r c -/

[reply]