that you have to select columns because you want to use them in other parts of the SQL statement is a limitation some databases has. Its a stupid thing that that must be done, just bad design of the database itself.
It shouldn’t matter if you just want col1 then you just want col1 if the database needs somehow also col2 then thats fine that it adds it under the hood but you won’t have to select it and you won’t get it.
In the end it doesn’t really make sense that this is a requirement.
Hi John
john.allen:
Hi Robert,Yes I’m planning on going to Servoy World and I’m looking forward to meeting up again!
First to this thread though!
Good to meet you at Servoy World, talks will be very interesting as we have now already some experience with Servoy
john.allen:
I’m a little confused by some of your statements and/or I disagree with some of your conclusions. Let me start though by asking:Do you intend to simply view this dataset or do you intend to edit this dataset? It is a pretty fundamental question, I think, in approaching anything in Servoy and it isn’t clear to me what you want to do with this data once you have it.
Very often it’s a mixture of being able to edit some fields where others are read only. There are cases where the data is only displayed.
As far as I understand you, you suggest using views for data display only, do you?
john.allen:
If I had to pick out the single biggest feature that puts Servoy in a completely different league than FM, it is the separation of database (with data) and the business logic/rules. I think the hardest thing for people coming from an FM background to Servoy is allowing their database to do the things that the SQL database does best and NOT trying to put everything down to Servoy and do everything through Servoy just because you can. THAT is what worries me in terms of bloatware and if Servoy tries to be everything to everyone. For example what does this mean?I think it’s a may be a bit similar as stored procedures, at first they were very welcome and looked at as step forward, but nowadays?
Are you saying you don’t see the usefulness/utility/benefits of stored procedures? Or you don’t see those benefits in conjunction with Servoy? I don’t understand.
Stored procedures have been developed over the last 20+ years in conjunction with all major SQL databases to optimize queries. Something that can take minutes to run as a standard query can run in seconds as a stored procedure, etc., with or without Servoy. What’s the downside?
Similar with views. You don’t want to directly EDIT data in views. Of course not. But what works GREAT with Servoy is to use a view as the basis for a form and then take column/row data from that view to relate back to the source table.column_row and edit with that. A view, after all, is really just an SQL SELECT statement. Throw in a ‘CREATE OR REPLACE VIEW AS’ in front of your query, make it dynamic to allow the user to define the ‘subject_code’ and you have your form. Using SQL hand-in-glove with Servoy is not workaround, FM-style programming. Far from it in my book. It is taking advantage of, working with and maximizing the qualities of your SQL backend. Otherwise might as well have simply a bunch of Excel sheets as your backend and use Servoy to ODBC your way around it!
As you might remember I used to be a Unix/Oracle guy so I agree with you regarding FM. Although the separaion of model is very good, it’s a bit different for separating view and controller (MVC paradigma). So for example in WebObjects the 3 are really completely separated. But after all one is commited to a tool/environment if we use one, so separation does not solve everything and I am quite happy to have the database separated in such an elegant way.
I have no problems with views and are looking forward to Servoy World to see how you use them, I think they have beside (obvious) limitations many nice properties. So I am not at all saying I wouldn’t use them if it is appropriate and as you say it is for some use a maximising. But my problem described in this threat has nothing to do with views (or I don’t see such a relation), it’s a simple SQL poblem not being able to specify other than pk attributes.
I think the downside of stored procedures is beside others their portability, the use of one database/vendor specific language for stored procedures but see for example the following article I just recently read for more arguments pros/cons (the article is a random selection, there are many others): http://www.oreillynet.com/databases/blo … roced.html
Thanks a lot for your opinion, it’s very good to hear what others think about a certain problem/solution)
Best regards, Robert