It was great that you could move from ISAM to SQL databases with hardly a change in code, but there a lot of of situations where having your application able to (with the security clearance to) directly send delete/add/update commands to actual tables would be considered very risky behaviour. I’d also like to see some improvements in the way Clarion communicates with the database. At the moment I will generally set up my data tables in the database, and make changes there too, and having the Clarion dictionary makes me have to work on that stuff twice. I think top of my list is that you should be able to have a dictionary that leaves handling the data and tables to a SQL back end, and the Clarion “side” of the dictionary just deals with the other stuff (mainly the control associated with the column).
Like everyone I have my ideas about what would make Clarion better.
I had a quick look on the web and I would say that Clarion is in the sweet spot between the easy but inflexible templates where you can get your basics, but not really customize, and the ones where you have to write a lot of low level code just to get simple things done. I think if you’ve found it and are productive with it, you should stick with it. You could bind directly to an Order if you really wanted to. That may or may not be applicable to what you’re doing.Įditing this to mention that if you’re binding your fields to a UI, binding support is going to be provided at the whim of the UI framework and/or View Model framework of choice – the View Model here serves the same purpose as the Window property dialog in Clarion where you can set up local variables and expressions to which you can bind controls. Some EF providers will let you scaffold the FILE definition from the database schema if you’re connecting to one that already exists. The tables are defined similarly to a FILE structure and you can reference the columns directly in the query functions, like var oldOrders = (o => o.OrderDate < (-30)), and oldOrders becomes a collection of Order objects that you can do whatever with. Unless I’m misunderstanding you… For data access, Entity Framework might be the closest fit.
0 kommentar(er)
