[Firebird-devel] Re Planning the post v3 development
Hi Dmitry, responding to your request, there is one thing Im really missing. What do you think about a SNMP function. Currently it is very hard for us to monitor Firebird performance over the time. It would be great to collect information about the server status via Nagios or Zenoss. So we can see when are the peaks in our customers memory. When are the most people active. Maybe there is a way to track the database growth. If we are able to poll the data from firebird server, Nagios or Zenoss can create some informational graphs. From my point of view this would be a great and helpful feature. What do you think? Kind Regards, Martin Köditz -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4544) Allow hiding source code of procedures and triggers in FB 3
Allow hiding source code of procedures and triggers in FB 3 --- Key: CORE-4544 URL: http://tracker.firebirdsql.org/browse/CORE-4544 Project: Firebird Core Issue Type: Improvement Affects Versions: 3.0 Alpha 2, 3.0 Alpha 1, 3.0 Beta 1 Reporter: Carlos H. Cantu As discussed in fb-devel, there should be a way to hide the source code of procedures and triggers in FB 3, either by allowing the long-time-used hack of nulling the source code in the system tables, or implementing an official way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Using isc_dsql_prepare_m instead of isc_dsql_prepare
On 12-8-2014 22:10, Mark Rotteveel wrote: On 12-8-2014 22:06, Adriano dos Santos Fernandes wrote: On 12/08/2014 17:01, Mark Rotteveel wrote: On 12-8-2014 21:24, Adriano dos Santos Fernandes wrote: On 12/08/2014 16:17, Mark Rotteveel wrote: Am I correct to understand, that in the C API isc_dsql_prepare_m will allow me to specify the database information items to request together with the statement prepare, allowing me to circumvent the allocation and handling of XSQLDA, and instead gives we a response buffer that I can process the same as I already do in the wire protocol implementation? Yes, you're correct. Thanks, Does something similar apply to the other _m methods? Yes, and the _m methods are the ones we put in the new API. Non-_m (who uses SQLDA) methods are wrappers for the _m methods. So as you see, as you need to maintain methods dealing with buffers, it's probably better to depend on the _m methods instead of SQLDA/SQLVAR too. You can look the details in why.cpp. Great, this greatly simplifies how I handle things and will allow me to reuse more parts of the pure java implementation. As it turns out, I have to ditch my plan to use the _m methods. Creating the message buffers for execute/execute2 in the correct way turns out to be a bit more complex with all the platform dependent alignment stuff that goes on in UTLD_parse_sqlda. This unfortunately leads to brittle and hard to follow code. And unfortunately you can't mix _m and normal methods, as isc_dsql_execute fails with an isc_unprepared_stmt (Attempt to execute an unprepared dynamic SQL statement.) if you use isc_dsql_prepare_m instead of isc_dsql_prepare. Mark -- Mark Rotteveel -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
