Forums Feature Suggestions /mysql_support

I would like to request the addition of mysql to the application. The only worthy methods that are in use today are by $dll or $com. Even then the use of mysql is nearly constant at times and the use of $dll will lag the application a lot.

/mysql_connect
/mysql_query
/mysql_close

Also since multiple queries are queued in a connect session. This may even be simplified by using an alias like $comcall or specifying a signal event to call, or last but not least instilling some sort of events as with on *:sockopen:*:{

on *:mysqlopen:*:{
}
on *:mysqlresult:*:{
}
on *:mysqlclose:*:{
}

This would make a lot of lives easier I know. At the very least it would add another spectrum of events to follow.

Are you actually complaining about the overhead of $dll itself, or do you just want an asynchronous MySQL API? Why can't a DLL provide such functionality instead?

I am not complaining. The functionality of the $dll command is fine in itself. However to reduce overhead and as well to increase productivity with mysql based connections it would be beneficial to have such support. The $dll command works fine and dandy however it does have its limitations as do all commands in any language. That is why they create new commands to customize usage.

I'm sorry but that does not answer my question. What limitation of $dll are you talking about specifically? How would integrating a
MySQL API into mIRC overcome this limitation?

use sockets

I was unaware the suggestion area was a flame session.. I am suggesting this simply because of the speed and cleanliness that it will provide. Simplicity first. I am not debating the fact it can be done with mIRC in other ways. In fact everything in mIRC can be done with other applications. However, the beauty of mIRC is the Simple format and ease of use. Had no one suggested the use of the socket in mIRC then where would it be today?

The point being this is a request and requires no flaming or truly any replies whatsoever.

How did you read any of this thread as a flamewar? Sat asked you multiple valid questions which you've completely evaded twice now.



These are perfectly valid non-flame questions.

On a sidenote, all of those events can be implemented with the ON SIGNAL event as:



Making the dll asynchronous as Sat pointed out would help with speed issues. I see no reason why mIRC would need to provide this natively. Seems perfectly capable of being scripted.

True, you can script it.

$dll
$dllcall
sockets
COM
WSH

in whatever you please.. Very true. However all these come at costs. Costs of speed and memory. This being code in the lower level will speed up the usage, as well as lower the cost of accessing. For those of us who use mysql in various ways in one instance of mirc. This being hardcoded into the executable will greatly benefit the usage.

As I stated before it can be done, and I've done it in all these ways. However, the cost is too great when you use it a lot. Especially simultaneously, I'm sure you would now find a reason to critique my usage of mysql in multiple facets. However the use of mysql is necessary and I am merely requested the fact that it be added.

Hence I take offense to the fact that there need be a fight over my request. I paid for mIRC unlike 50%+ of the users. I do take pride in making it better, as well do many.

I think you're seriously overplaying the speed benefits of having this built into mIRC. We're only talking about an interface (I hope), not an actual MySQL server being somehow embedded into mIRC so the speed benefits are negligable over a properly designed DLL. As is the convenience since you'll still need to install MySQL unless it's being hosted remotely (in which case the speed of a DLL call is a non-issue relative to a remote connection).

If there were some standard interface mIRC could implement to work with multiple SQL databases I'd agree it would be nice to have it built into mIRC. Obviously that's not possible* so for my part I don't see any reason to add support for one specific database. PostgreSQL, Interbase, Firebird, or SQLite could all be implemented with the same rationale. Of course adding them all would be crazy and that brings us back to the reason mIRC has DLL support in the first place - so that niche features can be added for those that need them without putting the burden of development and maintenance on the mIRC developers.

By the way I don't see any fight going on here. You're taking it far too personally that not everyone agrees that this should be in mIRC.

*Note: As has just been pointed out to me. mIRC could implement DBMS-agnostic support using ODBC. Perhaps this would be an appropriate way to go assuming the development overhead isn't too great.

I find it very odd that you consider this a "fight". We're merely asking you to qualify your statements. Making a feature suggestion does not automatically qualify your idea as valid or justified, and it's helpful not only to us but to Khaled to explain *why* this is a necessary request.




Please qualify these statements. Have you ever benchmarked mIRC using dlls as a bridge versus a sample application that makes direct calls to a MySQL library? Please share those numbers with us so we can see the actual "cost" you claim exists. If you haven't done so, how are any of these statements justified? Why did you make them? Are you expecting us to believe you at face value?

Efficiency seems to be the entire base of your suggestion and yet you have not shown any actual data to prove it's an issue. How do you know it actually is an issue? This is what we are questioning... this should not be insulting, this is a question you should be asking yourself. Now I'm sure you put plenty of thought into this suggestion, so I'm sure you have data to share-- please share it, this would help to show an actual need for your suggestion.

theres sql scripts written in msl, just use one