One Thing Of Litte To No Consequence, And What Hopefully Is An Answer

Primary Keys
I was reading along and it struck me that you were using two primaray keys. That's a no no ;) I would recomend examining your data structure, and optimizing it a tad bit more. If you liked, you could even get rid of the news_id field, and us an autoincremental field. I would advise reading this for information on how to setup your database.

String data, right truncation
Now onto your real problem, the string error, I quickly googled and found this on a website. Some other monk will be able to varify if this is true:

What does a Link ODBC Gateway error of "String data, right truncation" mean?

This error is generated by the ODBC driver and suggests that you are trying to populate a table column which has a set maximum character limit with data that exceeds this limit. To avoid this problem, we suggest setting up your table's columns so that they have exactly the same data types as the formats of your form's fields (including size limitations).

Helpful? But wait, there's more! I did a tad bit more research on ODBC with some code I had from a while back, and found this: $st->bind_param($i, $sql, DBI::SQL_LONGVARCHAR);

I noticed that your code was missing a DBI::SQL_LONGVARCHAR, and wanted to see what the heck in meant. So I went onto cpan, and found the pertinant information for DBD::ODBC. Here's what it says:

Note: those trying to bind variables need to remember that you should use the following syntax:

    use DBI;
    ...
    $sth->bind_param(1, $str, DBI::SQL_LONGVARCHAR);
[download]

It's possible that there are more problems, or that these aren't the only problems, but I hope this helps you in your debugging process.

Gyan Kapur
gyan.kapur@rhhllp.com

Comment on One Thing Of Litte To No Consequence, And What Hopefully Is An Answer Select or Download Code

Replies are listed 'Best First'.
Re: One Thing Of Litte To No Consequence, And What Hopefully Is An Answer by Anonymous Monk on Mar 30, 2002 at 17:46 UTC
Not to get too far OT, but why is it a "no no" to have two primary keys? By two primary keys, you mean a composite primary key, right? (since you can't have two primary keys by definition -- you can have two candidate keys though). Either way, I think it's wrong to suggest that either composite candidate keys or multiple candidate keys is a design error. In many cases it's precisely the right thing to do, since you're trying to express the meaning of your data.	[reply]
Re: Re: One Thing Of Litte To No Consequence, And What Hopefully Is An Answer by Revelation (Deacon) on Mar 30, 2002 at 20:09 UTC
If you look at the database the user has, and the data given by that database, you will see that his composite key is a combination of a string id, and the time the news item was generated (or something along those lines). This is used either to reduce the risk of having a primary key used twice, as we're using two elements, or because of the user's lack of knowledge of SQL (there's no reason to use a composite key, if one of the keys in that composite key can be primary in itself.) I admit my statement isn't true, but it would have resulted in the correct application by the anon monk ;) (I have sinned.) The primary key is an attribute or a set of attributes that uniquely identify a specific instance of an entity. If you were to benchmark a statement using a composite primary key, or a one attribute primary key, you would find that they single primary key would go faster. (Try using SQL's `explain` feature. This goes with the standard perl notion, of doing things with as little code as possible, while maintaining maximum flexibility, and pumping out high performance. From what I saw of the use of this monk's primary (composite) key, it would be easyer to create either a random string, which would be verified by the database as unused as a key, or just an integer, using auto_increment for the key. Primary keys are used to speed up queries (for the most part), and using a primary composite key doesn't help that out. In some instances it is necessary to create a primary composite key, but for the most part a primary key should suffice. That's why I was hinting at the fact that a composite key was not necessary, but you got me on the fact that my statement is actually not valid, and was not thought out... my bad ;) Sorry for the tangent, but I thought it was necessary to explain my reasoning. Gyan Kapur gyan.kapur@rhhllp.com	[reply] [d/l]