Rant : No imports, no error catching ? come on !

Classic Servoy
41

Vince:
Which is the yes part, and which is the no part

Yes it does have some powerful and depending on your experience relatively complex import features. Judging by the rest of your posts I suggest you try before you rant/buy because you may find you are not able to do what you want.

NO it wont do what Filemaker does

What it is designed to do is provide a programmer more functionality than that currently offered by Servoy - this requires competent programming knowledge and careful investigation before purchasing/ranting that the product wont the provide the functionality you require within the skill level you have available to implement your solution.

From bitter experience having come from a Filemaker background I have found that:

a) Servoy will generally do exactly what is required provided I either code it correctly or get it done by a more experienced developer. I generally estimate the task over the cost before wasting a week and failing to deliver at my expense.

b) The plugins, particularly from IT2BE/Dr Maison work well and come with excellent documented examples.

c) Sometimes Filemaker is better for my solution based on my skill level and the time I have available over the cost the client can afford.

d) The community is very active, skilled and prepared to help and you may find it wise to respect the help/support and not bite the hand being offered!

Gordon

42

You do realize a foundset is in fact the result of a SQL query, right?

Sorry they aren’t : a foundest can be the result of many SQL queries.

  • User search for all articles named Hard drive
  • then delete 2 of them
  • Then create 3 records,
  • then omit 10 of them

Good luck to retrieve all the queries. That’s why servoy certainly did a convert founset to data object.

Also depending on your calculations you can do it in SQL as well.
Now if you use Servoy only objects in your calculations (like object properties like ‘is visble’, etc) then SQL won’t do. But for fields, forms, relationships they all translate to SQL since under water they ARE translated to SQL. And in SQL you can do IF-THEN’s as well.

You’re all fogerting something I’ve said in the previous posty. I want to create general export function. That works in every situation. I don’t want to write one export method for each import or export I have. And I want to be able to use servoy objects everywherre, because the power is in those objects.

If you think servoy objecst are for kids, and that they either useless or you have to replicate them, I’d say why bother with servoy then if you don’t use its features.

You’ll see that you can’t get the sql queries from the servoy objects that are indeed sql queries underneath. And that’s totally a shame, I agree.

So you can’t build a general export function.

Prove me wrong and show how to get the sql query of any of the relation you have directly.

Create the relation_to_sql(relationname) method. You’ll se you can’t get it without firing it up once.

Then, suppose you can get it, I then need to process that to add the fields list I want to get, EVEN if there’s calculated fields in it.

Finally I want to be able to get all the related or the first related field of a one to many relationship.

So the GLOBAL method I want to write is

foundset.ExportData (MasterTable_name;List_of_fields_and_related_fields_name;All_or__one_related_records;Destination_file_or_toftp)

So The method should :

1 - figure out the foundset
2 - figure out the relations
3 - figure_out the related_fields
4 - figure out the calculated fields
5 - Get_all the related records

I’ve almost done it, but I can’t process calculated fields.

It appears to me that you can’t really write a general expor function, because servoy doesn’t give you access to the required information you need from servoy objects to replicate them in sql.

43

Tnx for finally telling us what you want.

Regarding the SQL underlying a foundset: Servoy DOES take care of all the inverts, omits etc, so the SQL returned by databaseManager.getSQL(foundset) is the correct SQL for your foundset.

If you want to get the SQL for a relation:

databaseManager.getSQL(forms.formName.relationName.foundset)

Regarding exporting calcs: That why we have Stored Calculations: If you as a developer decide users ought to be able to export a certain value that is displayed on your form, store the value in a field or if the value is the result of a calc: make it a stored calculation.

So, if you say you’re almost done, but you can’t process Calculated fields: there’s your answer.

Regards,

Paul

44

Thanks pbaker,

But what if a caculation use a related field ? a global ?

and what about aggregations ?

Can you put stored calculation in a portal.

45

Stored Calculations work just like unstored calcs and thus can use every available object.

The only difference is that the result is also stored in a column in the backend DB, and thus can be queried using SQL.

Inside Servoy, a Calculation (stored or unstored) is just a dataprovider, so anything that can display a dataprovider, including a portal, can display a (un)stored calculation.

Paul

46

Ok but does the simple fact of launching a sql query will update the stored calc ?

Otherwise I will have to update all the stored calc with a loop, and that will take considerable time.

47

Why would running an select statement update the cals?

Cals are updated by Servoy when the data they depend on are changed, so if you change the underlying data in the scope of Servoy, the calcs are always up to date.

Paul

48

So if I have a stored calc that’s the sum of the related fields value, then the simple fact that cahnging a related value directly in the related table, will update all the stored sum of all their parent records ?

Or if, the stored calc involves a global fields. When changing the global field value, servoy will update all records of the table/or foundset ?

49

Yes, if you update data inside Servoy on which Calculations are dependant, Servoy will update the calcs automatically and in the case of stored calcs, also store the new values in the backend DB.

Note: Stored Calculations have a scope wider than 1 client!!! So, if you alter data which will fire a recalculation of the stored calculation, the new result will be stored in the DB AND this dataChange will be broadcasted to ALL other clients. so, stored calculations are not ment for session specific values.

Paul

50

I’m sorry pbaker but that’s untrue, servoy doesn’t update all the stored calc needed.

I’ve just tried this :

3 tables :

articles : ref / designation / cat_id
art_to_cat : ref / cat_id
cat_names : cat-Id /name

I’ve added a third filed in art_to_cat which is a stord calc called c_name

so art_to_cat is now : ref / cat_id / C_name

this c_name is the related cat_id name fetched from the cat_name table.

Then I ran a sql select in the articles table with a join on art_to_cat C-name

When I change the name in the cat_names table, only the record that has been displayed by the form is correct, the other records are all wrong.

So servoy DOES NOT update all the records whenever a value used in a calcultion is displayed.

Hence my desire that a select actually updates the vallues. So there’s a need or such updates.

Servoy dev user guides states this

When you create a stored calculation, it is not immediately calculated for all rows in a foundset. To
force an update of the stored calculation value in all rows, you can use this loop:
for(var i=1; i<= controller.getMaxRecordIndex(); i++)
{
controller.setSelectedIndex(i);
}

so it doesn’t behave as you describe.

And by the way, adding that loop just took me 47s, before my method (which was just the select) ran in 1 second

51

As you can see in the docs you found, it states that if you create a NEW stored calculation, Servoy doesn’t calculate that field for all records in the table.

This we don’t do, because during DEVELOPMENT it would cost too much overhead, because you might be creating and deleting calcs in the process, or altering the definition of the calc along the way, and the table on which you base the calc might have millions and millions of rows in it.

Hence, if you create a NEW stored calc in your DEVELOPMENT environment and you need all EXISITNG records to get the correct value, you need to loop through all records ONCE.

Paul

52

Hence, if you create a NEW stored calc in your DEVELOPMENT environment and you need all EXISITNG records to get the correct value, you need to loop through all records ONCE.

Ok so that’s just what I did, I changed my name, and then looped through allrecords.

Obviously, 47 seconds later vs 1, it was ok. All record got the goo value.

So, I changed my name again, and ran my export function WITHOUT LOOPING.

And of course, it got the old values, not the new one :-(

53

Vince:
And by the way, adding that loop just took me 47s, before my method (which was just the select) ran in 1 second

The following function is probably more efficient than the loop:

databaseManager.recalculate(foundset);

Hope this helps.

54

Thanks Roclasi,

but the recalculate doesn’t work. Maybe that doesn’t work if the calc fileds involves a relation ?

55

So I verified that, even if you have stored calc, you have to have the fields on the form and perform a loop so the stored calc updates.

But that only works for the first related field. If there’s several related fileds, the other ones, even though they’re displayed with a portal aren’t updated.

so I’m stuck !

I think that a serious export function is needed because they’re no way to code it

56

Can you share your code here so we can get a better perspective what you are doing and why things aren’t working for you.

57

For you Filemaker developers, brain dump on how to get data from Filemaker to Servoy without throwing your back out:

http://www.servoymagazine.com/home/2007 … tting.html

Vince: There are elements to your strong opinions that I like. Hopefully you will be just as vocal when you start discovering all the ways Servoy helps you out.

And you have to admit that there are very few technologies where when you have a problem you get answered by various engineers and even the president of the company in question.

Welcome to Servoy land. It does indeed rock :D

58

Hi David,

I’m honored that my thread illustrates your excellent servoymagazine article.

Howewer, my import export rant, is not about getting my filemaker data to a new servoy solution. I know that my Filemaker solution is not the pinacle of database design. So I’ll rewrite it from scratch in a good way hopefully using servoy.

But regular scripetd imports and exports are mandatory for me, and now I’m worried because I see no way to do the export right because of calculation fields, and calculted fields that involves realted data.

So it appears to me I shouldn’t use calculation fileds if I want to be able to export any fields like I did with filemaker. And frankly that’s a huge letdown, because now I see that every calculation/aggregation fields can’t be used If I want to export them. Moreover stored calc doesn’t refreshs

So I’m really start to think that a lot of hig level feature of servoy : relationship, valueliste, calculations etc… are just worthless. Because you can either do sql queries which are fast, or use servoy objecst which are slow

So I’m wondering what’s the point of servoy, If you have to rewrite everything in sql

59

Hi David,

I’m honored that my thread illustrates your excellent servoymagazine article.

Howewer, my import export rant, is not about getting my filemaker data to a new servoy solution. I know that my Filemaker solution is not the pinacle of database design. So I’ll rewrite it from scratch in a good way hopefully using servoy.

But regular scripetd imports and exports are mandatory for me, and now I’m worried because I see no way to do the export right because of calculation fields, and calculted fields that involves realted data.

So it appears to me I shouldn’t use calculation fileds if I want to be able to export any fields like I did with filemaker. And frankly that’s a huge letdown, because now I see that every calculation/aggregation fields can’t be used If I want to export them. Moreover stored calc doesn’t refreshs

So I’m really start to think that a lot of hig level feature of servoy : relationship, valueliste, calculations etc… are just worthless. Because you can either do sql queries which are fast, or use servoy objecst which are slow

So I’m wondering what’s the point of servoy, If you have to rewrite everything in sql, think about upfdating all fields etc.

Filemaker did all this for free, including refreshes now I need to redo it, but I can’t because servoy mix sql and its own runtime

60

Vince,

I too am a recent convert to Servoy and I too experience the growing pains of learning a new product! I hear the challenges you are facing!

However, amidst your concerns, I think it would be good to also reflect on the many good things that Servoy is doing:

  1. The architecture for their product is exemplary. I come from an architectural and IT management background for large scale BEA/J2EE/Oracle deployments. Vince, there is a lot of quality architecture in this product. That exists and is in spite of my muddling about trying to learn the product (just like any other student) … complete with my many glaring errors, amusing lines of code and other digressions.

  2. Yes, there will be features found in other products (like db imports in FMP) you will not find here at this stage of the business and product maturity cycle. It is always a challenge when one is behind the 8-ball on a project and that “really important feature” is not readily available. However, be encouraged that there are also many other (important) features you will find here that are not readily elsewhere.

  3. The Servoy team is working hard and wisely. I don’t know them personally at all. However, I have watched their turnaround and response time and sensible adjustments to product direction. This product has the earmarks of quality engineering and thinking.

  4. There are very real constraints that ANY growing company has when it comes to adding features. These range from financial constraints (development takes $) to time constraints (features can only be added at a certain rate - the critical path for requirements analysis and architecture/design takes time … including some necessary “gestation” time to get it right). These important features and low-level architectural items can temporarily bump important other important features (like data import/export). Failure to build foundations first only leads to additional grief later on (ahem … there are other market and image-driven short cuts that sacrifice engineering quality out there … no names mentioned).

  5. I think it is wonderful that you have a responsive forum to interact with. So often, we see closed systems where one’s need goes into never-never-land.

  6. I think Servoy is doing a good job of balancing third party tools (like the IT2BE plugins and beans) and not jeapordizing overall market buildout here by simply "adding partner toolsets at a partners expense (like db import plugsin) " into their internal build out … so, perhaps consider other commercially available tools to help here like IT2BE.

  7. Finally, I would encourage you to encourage Servoy as well! They too are regular folks with feelings just like you and I: I am sure they would appreciate a positive tone amidst the many tight deadlines and challenges they must have with growth, new releases pending and a major upgrade (Eclipse) forthcoming.

If you wish further dialogue, kindly post to the cafe: it really is the appropriate place for this topic. My very best wishes with your project and that it is going well for you!

Sincerely,

Michael