Re: anybody used prepared statements in 4.1 succesfully?
Since you aren't using the C API directly, you should make sure your API is actually using prepared statements. I don't know anything about Connector/J, but for example, last I checked, the Perl DBI mysql modules didn't really prepare statements when you called the prepare method. This is of course because they haven't been upgraded to use the new features yet. Even if you did use the C API, I would be surprised if you get prepared statements working successfully. In my experience they have major bugs, at least in the current 4.1 alphas. Hopefully these bugs get fixed real soon now. Of course, if other people don't find prepared statements to be buggy, I would love to hear about it, since I really, really want them to be working properly. Hope this helps, Richard On Thu, Jan 22, 2004 at 11:59:08AM +, Brian Power wrote: Has anybody used prepared statements in mySQL 4.1 succesfully. By succesfull I mean quicker ! I have some prepared statement in my app and they take just as long the second++ time as they do hte first. My querys may need to be optimized (i just moved over from Access), but even so, shouldn't they be quicker the second time around. Im using java and Connector/J 3.0 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: anybody used prepared statements in 4.1 succesfully?
If you have the right level of logging turned on, you will see evidence in your query log. Generally you see command sequences like Connect, Query, Query, Query, Quit. With prepared statements you would see Connect, Prepare, Execute, Execute, Execute, Quit. I don't know off hand if there is a good way to check if you don't have everything being logged. Nor do I know of a more quantitative measure. I'm pretty new to mysql. Richard On Thu, Jan 22, 2004 at 08:42:56AM -0500, Sid Lane wrote: on a related note how can you verify that you're actually using a prepared statement (re: not reparsing)? in Oracle you can watch ratio of executions/parse_calls in v$sqlarea but how can you measure their effectiveness in mysql? obviously you can infer it with comparative tests of execution time/CPU load but is there a definitive/quantitative way to tell/measure? just curious (though I freely admit I've yet to even download 4.1; still proof of concepting on 4.0 so sorry if this is a RTM ?)... -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: anybody used prepared statements in 4.1 succesfully?
On Thu, Jan 22, 2004 at 01:51:09PM +, Brian Power wrote: do any of the dudes involved with mySQL read this forum ? even though I didn't pay for support would they respond to a direct email ? My experience is that if you aren't filing rock-solid bug reports, and you aren't paying, the developers don't want to talk to you. Not sure how good the support you get is if you are paying, we haven't started paying yet, we are still trying to qualify MySQL 4.1 as a valid platform for our needs. My experience is also that the sales-people are less than responsive, and not so hot at understanding the technical details of what you are trying to sell (took me quite a while to explain that prepared statements were something they were going to have in 4.1, and were not the same thing as stored procedures, which are in 5.0). In fact, I have to call up my sales guy today and kick him again, becuase I still haven't heard a date when I can get a pre-release of 4.1 with actual functioning prepared statements. Of course, this could all the the particular developers/salesguys I was talking to. Your mileage may vary. And if anyone has any tricks for getting better service from MySQL Sales and Sales Engineers, I would love to hear them. Richard -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: email attachments, stripped, coverted to text and inserted into MySQL
On Tue, Jan 13, 2004 at 09:41:57AM -0400, Vernon Webb wrote: I've been asking around for awhile without a solution to this problem and thought I'd post it here perhaps some one will know of a script that will help. I need to have emails sunmitted to a database field but more to the point I need to have the attachment stripped and added to MySQL. People will be mailing in Word documents and pdf files that I need to be inserted into the database. I'm assuming there has to be a script that I can run that will strip the attachment, convert to text file, and insert into the database. Anyone heard or know of anything? I don't know of an existing script. I would probably just write something quick in perl using MIME::Tools or in python using mimetools. Both offer easy processing of MIME messages (ie, modern message with attachments), and their languages also have good database bindings. Richard -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Prepared statements in embedded MySQL
I was wonder if anyone here could comment on when prepared statements might be available in the embedded server, I would find it very helpful. Will they be in the 4.1 release? Are there plans to add support in some future release? Thanks, Richard Tibbetts -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
C API Prepared Statement Interface - MYSQL_BIND
I am finding the documentation located at http://www.mysql.com/doc/en/C_API_Prepared_statement_datatypes.html on the C API Prepared Statement Interface to be a bit unclear. In the MYSQL_BIND datatype, when using mysql_bind_param() and mysql_excute() to pass parameters to a prepared statment, how does one specify the length of the parameters that will be passed? There are two fields, buffer_length and length, both of are documented to specify the length of input arguments. For buffer_length we have: For character and binary C data, the buffer_length value specifies the length of *buffer when used with mysql_bind_param(). In turn for length we have For input parameter data binding, length points to an unsigned long variable that indicates the length of the parameter value stored in * buffer; this is used by mysql_execute() One might conclude that mysql_bind_param() uses buffer_length to tell the server about the max argument length, and that mysql_execute() uses length to decide how much data to actually send for a given invocation. Is this correct? Thanks, Richard Tibbetts -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
