database related question

[dartes]

hi Bernard
thank you for this very thorough explanation. I have indeed a feeling of outgrown-ishness with FM. You do not know it so you cannot understand what I mean; but do not misinterpret me: I still believe it's a very good tool (even if I think it could be way better if they were more generous with new functionalities).

I was very much attracted by Panorama when I encountered it (I have bought it) but for some reason it did not feel right. That's why I kept on searching.

Of course, my problem is not just a recipe DB. It was an example (even if I am actually making one in FM).
I have made fully-fledged business solution for my business (with orders, invoices, contacts, salespeople and so on) in the past.
And in the future I might need CD-catalogues for distribution.
No, I think Rev is the right tool even if it will take some time before I can become productive with it.

My present circumspection (as I was expressing in my post) is mainly due to the fact that I was burned out by the previous experience (with Panorama AND 4D. Yes, feel free to think I am an hopless idiot or a money-waister, but I bought also a license for 4D). Even if I still like them both, a lot, I think I will not have enough time to learn more than one tool. And then for what? For a pro it may be just the right path to learn manifold skills but not for me. One it is enough. Especially if you wish to master it.

Incidentally, there is a 3rd party tool...

Yes, I am aware of that one. I did try it. Maybe I was little too quick in judging it but I could not make much of it. The results I had were very very poor and a research on internet broght some more discouraging opinions about it. And if you check, Rev is not selling it (or not anymore). The "buy now" link is taking you to their website. I thought that very suspicious!

I am sorry, because I really liked the idea of preparing a solution (like a prototype) in FM, very quickly, translating it into Rev and then with the new powerful tools at disposition, develop it further! Sky the limit! Ah, but life is never perfect!

Actually it could be a nice new thread... a discusiion bout FM Migrator. I might consider it...

[Bernard]

Hi Dartes,

I don't know any of these alternatives to Rev very well, as 7 years ago when I went through the comparison exercise you are going through I eliminated most of them (including Omnis) for one reason or another, leaving me with Rev. I too was quite impressed by Servoy, although I did not want to be bound to a tool where there were client/runtime licenses.

But since I'd never heard of Panorama until you mentioned it I'd be interested to hear what you find limiting about it. Also, if it turns out that you may have the same problems with Rev, then we can warn you away from Rev Or maybe we can solve the issues for you.

During my survey I too bought various other tools, and never used them because they didn't live up to my expectations. Don't expect people to judge you harshly here or on the Rev lists. They are very nice people (I'm one of the least nice!)

About the table in Rev. Rev 3.5 now has a new powerful, DataGrid component (http://www.runrev.com/newsletter/februa ... etter1.php). Also, just a few months ago a great French Rev developer released a control called ListMagic, which also is a great improvement on the underlying (old) table control. We now have several choices for table presentation in Rev.

By the way, in case you don't know, the whole Revolution IDE is written in Rev itself. I'm pretty sure that none of those other tools you mention is written in the language/IDE we all use. Just looking at the way the IDE works should give you an idea of what is possible with Rev.

The issue will come down to whether or not you need the flexibility that Rev provides. It may be there is too much to learn before you see the results you want.

[dartes]

No, don't you worry Bernard, I know people is very nice here. And you are really one of them.
It was just a way of saying. I know of a lot of people throwing a lot of money on software (more than me actually). But what to do. Sometimes demo are not working long enough, sometimes is just avidity ("I want the real one, not just a **** limited demo!") and then making lot of stupid decisions!

About Servoy I had the same reserve: too much expensive if you want to deploy (I have the free unlimited trial). What I liked about it is that it has a lot of features similar to FM (I think one of their creator was an important guy in the FM developer community). And also that, to work with it, you need standard languages (like javascript and sql that can be useful in many other situations)

For Panorama I will not dare to express any opinion. Not enough experience. Just it did not feel right for me. Maybe I was not able to make appealing GUI with it (for me it is very important the graphical appeal. Another of my hobbies/business needs is to play around with Photoshop and Illustrator). The same drawbacks I found in Alpha 5 and Servoy...

The issue will come down to whether or not you need the flexibility that Rev provides. It may be there is too much to learn before you see the results you want

As I said, I am not afraid of learning (but only one tool). Is also a kind of hobby (of all the tools I was playing around there was also Python, a REAL programming language...)

[sturgis]

Yeah that is kinda what I was saying, but its a personal preference. If you're going to put in the effort to run a database back end, it almost seems as though you should store all your data there. In the case you described it does sound like it might end up being easier to do the internal storage for the recipes and such, and use an external for orders.

If you did go with a database for the whole shooting match, you could simplify my first database example and get rid of the link tables. Just use delimited ingredient lists in your preperations, so it'd be like the table I described. prepId, prepName, prepDescription, prepIngredientList
for dish table, dishId, dishName,dishDescription,dishPrepList

This would require some extra code to break down the lists and then pull the related records, but it should work.

Unfortunately, I've been out of coding long enough do to various reasons, that I'm getting in way way over my head with this stuff. Hopefully Bernard and all can clear up things better than I can.

hi Sturgis
yes, I think this is the way. Simple and clean. I do not think the solution will never grow over the 100 or 200 records (I mean lines). But for the "orders" records, in which case I can just use a database backend...

you end up supporting 2 solutions to the same problem

by this you mean 1: storing in Rev cards and 2: storing in a database?
So if I need an unlimited numbers of records for "orders" better to be consistent and use the ext database solution? Is tha what you mean?

[FourthWorld]

Ah (sorry to bother so much):

No bother - that's what these forums are for.

I was reading of somebody saying that he would have wished for a better support of real table in Rev (he was saying: "not just text fields with tailfinn work" or something). I do not understand completely what that could mean, but you see, considering my background, tables ARE very important. I would not be happy not finding them! Any plan for future releases (as far as you know)?

Good news, bad news and more good news:

Good News:
Rev's field object makes a great table for many purposes. Just set the hGrid and vGrid properties to true, drop any tab-delimited data into it, and it's displayed in nice even columns. The buffering system used under the hood is profoundly efficient, making scrolling of even large lists more graceful than Excel or many other tabular displays.

Bad news:
The native field object lets you align columns to the left or the right, but only for the whole field. So if you want to display text left-aligned with columns of numbers right-aligned, the simplicity of the native field object won't be your solution (at least not right now, though there is an outstanding request to have independent column alignment in fields:
http://quality.runrev.com/qacenter/show_bug.cgi?id=2282 ).

Good news:
Rev 3.5 now provides a nifty new widget called DataGrid, which lets you define even very complex tables with relative ease, almost as easy as one would do it in FMP.

A DataGrid control is a group that contains any number of rows, with the row being defined elsewhere by just assembling whatever objects you want to use to represent a record. A row can contain fields of course, but can also contain checkboxes, images, and even other groups -- any controls you like.

While it's a lot more work to set up when all you need is a simple text grid with independent column alignment, you can use it for that.

But where it really shines is in all the other types of lists you might want to make, using any combination of controls you can imagine.

You can make your own custom lists using groups as rows within another group, but it's not easy to manage and you'll find some limitations if you try to actually build out all of the rows of a data set at once (groups in Rev have a limit on the formattedHeight, and cannot exceed a total of 32,767 pixels).

But the DataGrid uses some very clever scripting which builds only the rows needed for display, taking care of managing which rows are displayed according to the scrollbar with remarkable efficiency. It's a truly fine work.

If you haven't checked out v3.5 there's much to love in the new version, but as an FMP fan I think you'll find the DataGrid especially compelling.

[FourthWorld]

For Panorama I will not dare to express any opinion. Not enough experience

Me neither, but one of the things that caught my attention was that it's RAM-based. This offers a lot of performance advantages over page-from-disk systems most other DBs use, but at the price of scalability. It's hard to cram a million records into RAM, but then again how many people actually need to deal with a million records?

This conversation motivates me to try to squeeze in some time to document my data management library. It's a busy season with client work right now, but as I come across these discussions here it seems it may be useful to make it available through RevSelect. It's not nearly as efficient as the highly-optimized routines at the core of Panorama, but being also RAM-based it offers reasonable performance for small data sets (<50,000 records), and since it uses native Rev custom props for storage it's quite flexible, very useful for making document-centric apps for which traditional DBs are a bit cumbersome.

Back to work for me....