Re: [dba-users] MSA funtctionality

[Andrew Jensen]

Howdy Marc I was putting forth my short list if you will, and hoping for feed back. Seems to me like a good way to give input. Perhaps if we talk about things here then when one of us is sure enough they will enter an RFE, and perhaps in talking about it one may decide to not clutter up issuzilla with an RFE that has not been thought all the way out. First - Back to reports. This issue is worked at, as far as I can tell. And for the time until it fits your needs you can use any report maker out there, try searching www.sf.net for the keyword and you'll get anything you can think of (and mostly even more). Actually if you look at the other times I mention this I acknowledge that there are plenty of report writers available. I have made this point before linked to another point.. That for now if you create an embedded database file then for now the only report options are either the report wizard or writing code to put use Calc or Writer as the report document. I have mentioned that the fastest route to a solution would be a JDBC driver for the native database type. However, if OOBase could offer a robust report writer then combining this with the ability to pull data from all its supported databases becomes quite an asset. I have mentioned the work done with Jasper over the summer, and if there is thought of integrating that into OOBase meaning building a layout manager for the Jasper engine...well, that probably be just about what I am asking for. If that project is in the works, then I will switch from asking for the feature to asking "How can I help get it done?" Second - The Query Builder. Creating select queries is only the beginning. Update and delete queries are one of the strong points of MSA. At first this seems like more flash then substance, but it really is a feature that users make use of. Now add to this the ability to create pivot tables and you have a large part of MSA's usability for the non-dba. Since I stopped using MSA in Version 2 I'd like to ask you, what exactly is missing here? So far I had no problems building queries in OO.o. For upüdating and deletion: Design your query in the SQL view and leave it that way, should be enough in most cases. Distinction between types of queries would be a good thing, if you file an issue I'll vote for that one. I would be more then willing to enter a RFE, but wanted to hear what other people thought about it first. There are already issues about the query builder, just in the making select statements. Binary fields, sub selects and a few others. Pretty much I would lump these into birthing pains. But the delete and update queries are a horse of a different color. I know that they would require more work. This particular issue however, and the use of the report writer is something I did a little research on, for I like you gave up MSA a while back. I talked with a few people that I respect and have daily supervisory control over staff that make use of the tool. Both of these points where made strongly to me, and mind you this is the customer support staff at a vertical market firm whose products run not on MSA, one does use Jet..but we never talked much about that back in the development group..we just inherited it from a buyout..*smile*.. anyway we where an Oracle shop. Also on the OOOForum boards this seems to be a point, the use of the query builder to do data manipulation, that is make or break issue for a number of folks bosses. There is an aspect of the data manipulation by query functionality that users I have seen love. The ability to undue the changes. OK, so we know this is just a case of turning autocommit off, and doing a rollback. But they never had to know that, it is just done for them and they therefore feel safe. Have you filed an RFE issue for this one? Same as a above, I thought it better to talk about it first. Third - Upgrade to the StarBasic tnterpreter. The difference between trying to do a simple task in VBA and StarBasic is striking. StarBasic just must be pulled, kicking and screaming if necessary, away from the API and up to a 'business object' (or whatever term we come up with, a high level) level. Simple test, the second you find yourself needing to explain what MVC means, you have lost a third of potential scripters! If you also have the ability to use the API directly then all the better, but it just can't be the only route. If my memory doesn't fail or there has been some big restructuring in MSA then scripting in OO.o is not much more comlicated than MSA. Microsoft has no good understanding of what should be an object, a property or the other way round. I really disliked programming MSA. Your point in respect to OO.o is true, it lacks some form of object orientation. But for small scripting tasks like making a button do something this isn't necessary. People using OO.o base on that level are free to use Java or C++ for writing their own components aggregating things in an appropriate way. Yes, I'd like to see BASIC be fully "VBA-like", but the effort to get there isn't worth forgoing development in other areas of more importance. On this point I have no illusions about the scope of the work I am talking about. Truthfully I also have little expectation that it would make into a schedule anytime soon. Let me just give one small example of what I mean. Lets say I have a grid control on a data entry form. I want to know what rows the user may have highlighted. I drop a button on the form and call a sub procedure. How do I get the selected rows? Form.GridControl.Selection Nope thisComponent.CurrentController.getControl(thiscomponent.drawpage.forms.getByName("FormName").getByName( "gridcontrol")).Selection I know I made that a bit more then it needed to be, but hopefully you see my point. This isn't really the list to have this discussion on anyway I guess. I suppose it would be either API or UI. As for prioritizing, yes I know about that..and I can back off on a point if need be. Fourth - Multi user support. I have no doubt there where good reasons to have not supported this in the intial release. But you need to get it in there as soon as possible. I don't understand why you think base does not support multiple users. Or what you want to achieve. From the database side if you choose a server type database there is no problem. >From OO.o's side: I don't want other to use my personal installation, and in the sight of privacy this is no good idea. The only problem I see is to start with a single embedded type HSQLDB that later on should be used by a multitude of users. For this tasks there could and should be a small howto telling anyone how to switch from the embedded HSQLDB to a server type one. In the meantime you can look at www.hsqldb.org (hopefully this is right ;) how to set the db up correctly. This one...well..I might just be all wet :-\  You have a point, in fact I have made it myself on a few occasion. A few builds back I just couldn't get the file based or server based connections to work right and I suppose I just got off on this track. With RC1 this seems to be working much better, in fact I have already tried a simple migration using the Script command to move everything from embedded to server and then just switching the connection type on the ODB file. Seems to work pretty well. Here again I should think of being more pro-active. I will make a few more migration attempts to both file based and server based and when I am done will try to put together a small one page document that goes over the steps and any 'things to watch for' that I might find. Anyway, it's Open Source and you can do to it whatever you like. Use the source, Luke! Loved the movie...hate the sentiment, sorry. That side of open source in my opinion is a very sharp double edged sword. Not that it shouldn't be used, but when? That is a phylisophical discussion however for another time, and if perchance you and I ever find ourselves at an OOCon, maybe we can have it over a glass of beer. For right now, I am going to get back to building a small application for a new acquaintance. Who knows, enough of these little projects and I might even understand what I have here in OO.o? Andrew