I have a table in which I store some basic parts, let's say "level0 parts".
Then I have another table in which I store assembled parts: level1 parts (made of level0 parts).
Then I have a 3rd layer (level2 parts) where I store objects created by assembling level0 AND level1 parts (and I might possibly need a fourth layer).
In FM it is easily realized with relationship. How it is possible to do in Revolution?
database related question
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
I'm not au fait with FM, but I gather from a friend who uses it that it's a semi-relational db, and that relationships are kind of formed for you by point and click.
On that basis you could implement these relationships in any of the SQL databases that Rev supports e.g. SQLite.
However, probably the simplest action would be to use a group of Rev arrays as tables of parts.
On that basis you could implement these relationships in any of the SQL databases that Rev supports e.g. SQLite.
However, probably the simplest action would be to use a group of Rev arrays as tables of parts.
To get the parts from a level 2 component, you would sayput level0[partNumber] & comma & level1[partNumber] into level2[partNumber]
As I'm not sure what FM relationships are, please provide a fuller example if the above is not what you are looking for.put item 1 of level2[partNumber] into aLevel0Part
put item 2 of level2[partNumber] into aLevel1Part
hi Bernard
I love this forum. People is great here, so ready to help!
Yes, if you do not mind, I would really like to go a little deeper: I'm still evaluating Revolution and, even if I like it very much, I want to be a little surer before embarking on the long journey of learning a complex language (I'm not a programmer and before discovering it, I tried Alpha 5, Panorama, 4D and Servoy...). As you can see my main interest is databases...
Relationships in FM are like SQL joins (if I am not wrong) where tables are connected via unique keys. I guess a big difference is that they are more static: you build 'em and keep 'em (unless you want to redesign the structure). You do not build queries on the fly.
In my case I would have a table with basic ingredients (let's talk about recipes): like salt, butter, oranges etc.
With these basic ingredients you create some preparations (2nd level) like sauces, dressings and so on, which are not yet the final product.
And finally you have the actual course: "spaghetti with tomato sauce", in which you use both primary level (salt, butter) and 2nd level ingreds (sauce).
I do not yet understand arrays, but what you can do (using an external database and Rev) to solve this problem?
In FM exists a control called "portal", a kind of window or listbox, through which you can visualize only related records of choice (related by keys). Then you can sum, average or count them etc.
My problem is that, at the 2nd level, I will not have simple entities (residing in one field in a record) but an "aggregate" (in my example, the ingredients of a specific preparation).
If I want to know the cost of the basic ingredients it is simple: I just collect them in the market. But at the 2nd and 3rd level, I need the sum of different costs...
What do you think? I hope I made myself clear.
Anyway, thank you so very much, really.
I love this forum. People is great here, so ready to help!
Yes, if you do not mind, I would really like to go a little deeper: I'm still evaluating Revolution and, even if I like it very much, I want to be a little surer before embarking on the long journey of learning a complex language (I'm not a programmer and before discovering it, I tried Alpha 5, Panorama, 4D and Servoy...). As you can see my main interest is databases...
Relationships in FM are like SQL joins (if I am not wrong) where tables are connected via unique keys. I guess a big difference is that they are more static: you build 'em and keep 'em (unless you want to redesign the structure). You do not build queries on the fly.
In my case I would have a table with basic ingredients (let's talk about recipes): like salt, butter, oranges etc.
With these basic ingredients you create some preparations (2nd level) like sauces, dressings and so on, which are not yet the final product.
And finally you have the actual course: "spaghetti with tomato sauce", in which you use both primary level (salt, butter) and 2nd level ingreds (sauce).
I do not yet understand arrays, but what you can do (using an external database and Rev) to solve this problem?
In FM exists a control called "portal", a kind of window or listbox, through which you can visualize only related records of choice (related by keys). Then you can sum, average or count them etc.
My problem is that, at the 2nd level, I will not have simple entities (residing in one field in a record) but an "aggregate" (in my example, the ingredients of a specific preparation).
If I want to know the cost of the basic ingredients it is simple: I just collect them in the market. But at the 2nd and 3rd level, I need the sum of different costs...
What do you think? I hope I made myself clear.
Anyway, thank you so very much, really.
This should be doable. As you said, 1 table would have the basic elements, salt, pepper, etc. each with an id.
At this point, you could have the table for your preperations, this could be very simple. Preperation name and id.
A 3rd table would be for preperation ingredients, a link table.
It would contain the preperation name id, and a place for the ingredient id.
You could also have a quantity field in this table. This would be a many to 1 relationship table.
It would contain rows with preperation id, ingredient 1 id, amount. One row for each ingredient needed in the preperation.
Then you need a table for the finished dish. This could contain the dish name, and id.
Another link table, has the dish id, and preperation id's.
If you do it this way, you have a path to travel to get any information you need. If you want to know what dishes use oranges, get the orange id, use it to get all the preperation id's from the preperation link table, and use the results of that to get the dish ids from the dish id link table.
I'm still new at the hand written sql part to do all this, but the schema itself should be close to what you described.
At this point, you could have the table for your preperations, this could be very simple. Preperation name and id.
A 3rd table would be for preperation ingredients, a link table.
It would contain the preperation name id, and a place for the ingredient id.
You could also have a quantity field in this table. This would be a many to 1 relationship table.
It would contain rows with preperation id, ingredient 1 id, amount. One row for each ingredient needed in the preperation.
Then you need a table for the finished dish. This could contain the dish name, and id.
Another link table, has the dish id, and preperation id's.
If you do it this way, you have a path to travel to get any information you need. If you want to know what dishes use oranges, get the orange id, use it to get all the preperation id's from the preperation link table, and use the results of that to get the dish ids from the dish id link table.
I'm still new at the hand written sql part to do all this, but the schema itself should be close to what you described.
dartes wrote:hi Bernard
I love this forum. People is great here, so ready to help!
Yes, if you do not mind, I would really like to go a little deeper: I'm still evaluating Revolution and, even if I like it very much, I want to be a little surer before embarking on the long journey of learning a complex language (I'm not a programmer and before discovering it, I tried Alpha 5, Panorama, 4D and Servoy...). As you can see my main interest is databases...
Relationships in FM are like SQL joins (if I am not wrong) where tables are connected via unique keys. I guess a big difference is that they are more static: you build 'em and keep 'em (unless you want to redesign the structure). You do not build queries on the fly.
In my case I would have a table with basic ingredients (let's talk about recipes): like salt, butter, oranges etc.
With these basic ingredients you create some preparations (2nd level) like sauces, dressings and so on, which are not yet the final product.
And finally you have the actual course: "spaghetti with tomato sauce", in which you use both primary level (salt, butter) and 2nd level ingreds (sauce).
I do not yet understand arrays, but what you can do (using an external database and Rev) to solve this problem?
In FM exists a control called "portal", a kind of window or listbox, through which you can visualize only related records of choice (related by keys). Then you can sum, average or count them etc.
My problem is that, at the 2nd level, I will not have simple entities (residing in one field in a record) but an "aggregate" (in my example, the ingredients of a specific preparation).
If I want to know the cost of the basic ingredients it is simple: I just collect them in the market. But at the 2nd and 3rd level, I need the sum of different costs...
What do you think? I hope I made myself clear.
Anyway, thank you so very much, really.
Hi Dartes,
Perhaps we can take a step back, and see what it is you want to do with the tool. I have a friend who tried Revolution on my recommendation, but after trying to use it for a year or so, she gave up and took up FM instead. She's been very happy with FM ever since, and thinks her time trying to learn Revolution was wasted.
She likes building applications/tools but hates writing code, even in a language like Hypertalk/Transcript. She doesn't want to be able to build her own widgets, but wants the tool to provide them all for her. She's very happy in a point and click environment, and hates the idea of using something as "low level" as a debugger.
Are you just trying to see if Rev implements the same handy features as FM, or do your questions relate to a specific problem that you know how to solve in FM and you want to see if the same problem can be solved in Rev? The kind of query you are describing ("what's the total cost for all the butter used in this recipe") can be achieved in SQL using external databases, if that's what you want. However, that kind of query is going to be fairly complex (more complex than my FM friend would have the time for).
You say that in FM "you do not build queries on the fly". Code in SQL (or Revolution) has to be written, but generally speaking, it is not written on the fly, but new values are incorporated into the queries when the code is running that will effect some result. However if you do not know much about programming, then building (and debugging) complex SQL may be more work than you want.
There is a 'Database Query Builder' in Revolution which might provide some level of automation for you (in terms of connecting up user interface elements with an external database). And there are tools you can get that will allow you to build/modify your external database graphically, something like the way I take FM to work. If you'd like to see more about what working with Revolution is like, I'd suggest you download it and try some of the examples in the Resource Center. Or maybe just download the User Guide (http://downloads.runrev.com/userguide/userguide.pdf) and have a look through that at how one would work with external databases.
Maybe you can say what it is you are looking for in a tool in a more general way, and why FM is not that tool. From what I know of the tools you've listed it seems your interests are in rapid application development rather than databases per se. I had never heard of Alpha 5 and went to find out more but many pages on their website are missing. I did go and look at Panorama which I'd also never heard of - thanks for that, I'm learning new stuff too.
After my friend's preference for FM over Rev I wouldn't like to steer you in the wrong direction. I'm sure you are quite free to ask any questions you like in these forums regarding the strengths and weaknesses of Revolution compared to other products. I'm pretty sure that RunRev would prefer not to make a sale than have someone regret the sale in the future.
Perhaps we can take a step back, and see what it is you want to do with the tool. I have a friend who tried Revolution on my recommendation, but after trying to use it for a year or so, she gave up and took up FM instead. She's been very happy with FM ever since, and thinks her time trying to learn Revolution was wasted.
She likes building applications/tools but hates writing code, even in a language like Hypertalk/Transcript. She doesn't want to be able to build her own widgets, but wants the tool to provide them all for her. She's very happy in a point and click environment, and hates the idea of using something as "low level" as a debugger.
Are you just trying to see if Rev implements the same handy features as FM, or do your questions relate to a specific problem that you know how to solve in FM and you want to see if the same problem can be solved in Rev? The kind of query you are describing ("what's the total cost for all the butter used in this recipe") can be achieved in SQL using external databases, if that's what you want. However, that kind of query is going to be fairly complex (more complex than my FM friend would have the time for).
You say that in FM "you do not build queries on the fly". Code in SQL (or Revolution) has to be written, but generally speaking, it is not written on the fly, but new values are incorporated into the queries when the code is running that will effect some result. However if you do not know much about programming, then building (and debugging) complex SQL may be more work than you want.
There is a 'Database Query Builder' in Revolution which might provide some level of automation for you (in terms of connecting up user interface elements with an external database). And there are tools you can get that will allow you to build/modify your external database graphically, something like the way I take FM to work. If you'd like to see more about what working with Revolution is like, I'd suggest you download it and try some of the examples in the Resource Center. Or maybe just download the User Guide (http://downloads.runrev.com/userguide/userguide.pdf) and have a look through that at how one would work with external databases.
Maybe you can say what it is you are looking for in a tool in a more general way, and why FM is not that tool. From what I know of the tools you've listed it seems your interests are in rapid application development rather than databases per se. I had never heard of Alpha 5 and went to find out more but many pages on their website are missing. I did go and look at Panorama which I'd also never heard of - thanks for that, I'm learning new stuff too.
After my friend's preference for FM over Rev I wouldn't like to steer you in the wrong direction. I'm sure you are quite free to ask any questions you like in these forums regarding the strengths and weaknesses of Revolution compared to other products. I'm pretty sure that RunRev would prefer not to make a sale than have someone regret the sale in the future.
-
FourthWorld
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Bernard, good post.
Everything in computing, like most of life, involves tradeoffs. With crafting database solutions, the tradeoffs with various tools could be characterizes as convenience vs. flexibility.
We could put such systems in a spectrum, and listed in order of convenience to flexibility they might look like this:
CONVENIENCE
---------------
Bento
FileMaker
Panorama
4D
Alpha 5
Revolution
RealBASIC
Pascal
C++
C
-------------
FLEXIBILITY
( I know many consider Pascal a dead languague, but it's a damn fine one and sometimes I miss it <g>).
FileMaker lets you do a lot of stuff really conveniently, but when you're done it always looks like FileMaker. You're limited in terms of what goes in the menus, how the windows look, how much of the program behaves. But you can crank stuff out really quickly and for many solutions it's pretty great.
With Revolution you're definitely working harder to get the same results, but that assumes of course you want to same result. If you like how FileMaker apps look, and the features there meet your needs, it'd be almost foolish not to use it (esp. now that the latest version finally offers even-driven scripting, more than 15 years after the product was first released).
Rev is a good choice when you need something more than what FMP provides; more flexibility with your layouts, more subtle user interactions, more complete control over the menu bar, more rich media support, etc.
I don't know that I would venture to say one is "better" than another, since all these tools are good at what they do.
There's definitely a place for Rev, but it's not for those who don't like scripting.
Everything in computing, like most of life, involves tradeoffs. With crafting database solutions, the tradeoffs with various tools could be characterizes as convenience vs. flexibility.
We could put such systems in a spectrum, and listed in order of convenience to flexibility they might look like this:
CONVENIENCE
---------------
Bento
FileMaker
Panorama
4D
Alpha 5
Revolution
RealBASIC
Pascal
C++
C
-------------
FLEXIBILITY
( I know many consider Pascal a dead languague, but it's a damn fine one and sometimes I miss it <g>).
FileMaker lets you do a lot of stuff really conveniently, but when you're done it always looks like FileMaker. You're limited in terms of what goes in the menus, how the windows look, how much of the program behaves. But you can crank stuff out really quickly and for many solutions it's pretty great.
With Revolution you're definitely working harder to get the same results, but that assumes of course you want to same result. If you like how FileMaker apps look, and the features there meet your needs, it'd be almost foolish not to use it (esp. now that the latest version finally offers even-driven scripting, more than 15 years after the product was first released).
Rev is a good choice when you need something more than what FMP provides; more flexibility with your layouts, more subtle user interactions, more complete control over the menu bar, more rich media support, etc.
I don't know that I would venture to say one is "better" than another, since all these tools are good at what they do.
There's definitely a place for Rev, but it's not for those who don't like scripting.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Thanks for your thoughts on how the tools range between convenience and flexibility, Richard. I stick with Rev precisely because it seems to me to offer me the maximum power and choices, considering my programming ability.
It sure was an interesting few hours reading the Panorama web site, docs and movies. I like that their solution is scriptable in so many languages, but it doesn't seem flexible enough for me in terms of UI manipulation. Another issue for me is that on the server side I would use Linux, whilst their server is OS X only.
But it's great to see a small company like that thriving over 20 years providing development tools, and I'll certainly be keeping it in mind.
It sure was an interesting few hours reading the Panorama web site, docs and movies. I like that their solution is scriptable in so many languages, but it doesn't seem flexible enough for me in terms of UI manipulation. Another issue for me is that on the server side I would use Linux, whilst their server is OS X only.
But it's great to see a small company like that thriving over 20 years providing development tools, and I'll certainly be keeping it in mind.
hi Sturgis
thank you for the advice, I will work on it as soon as I have a little spare time.
But I still have a question (you will forgive my complete ignorance of sql): is it possible to save the results of sql queries? and could these results be referenced? If so I could keep a bunch of them, like virtual tables, for the 2nd and 3rd layer, and retrieve the data when necessary...
thank you for the advice, I will work on it as soon as I have a little spare time.
But I still have a question (you will forgive my complete ignorance of sql): is it possible to save the results of sql queries? and could these results be referenced? If so I could keep a bunch of them, like virtual tables, for the 2nd and 3rd layer, and retrieve the data when necessary...
hi Bernard,
thank you for your concern.
The fact is that I am coming from FM! For many years I have used it and created quite a few solutions, even complex. I used to be very fond of it. But lately I started to feel more and more frustrated with its limitations, mainly due to its lack of a programming language (like Richard is pointing out, they introduced "triggers" after so many years. There is something called "scriptmaker" but I would never describe it as a programming language).
I am not a programmer; I just enjoy creating my own solution for my business needs.
And no, I am not afraid of some programming; but I cannot dedicate too much time to it. That was my point: since I can dedicate just this much for learning a new tool, I want to be sure it is not a waste of time.
One nice side-effect of playing with code, I feel, is that, in the learning process, you refine your logical skills; a very good exercise to keep the mind sharp!
thank you for your concern.
The fact is that I am coming from FM! For many years I have used it and created quite a few solutions, even complex. I used to be very fond of it. But lately I started to feel more and more frustrated with its limitations, mainly due to its lack of a programming language (like Richard is pointing out, they introduced "triggers" after so many years. There is something called "scriptmaker" but I would never describe it as a programming language).
I am not a programmer; I just enjoy creating my own solution for my business needs.
And no, I am not afraid of some programming; but I cannot dedicate too much time to it. That was my point: since I can dedicate just this much for learning a new tool, I want to be sure it is not a waste of time.
One nice side-effect of playing with code, I feel, is that, in the learning process, you refine your logical skills; a very good exercise to keep the mind sharp!
hi Richard
nice chart, there! It seems that Revolution, falling right in the middle, is then the best choice! Sorry, I'm joking but still I think I agree with you.
(You forgot to mention Servoy...)
As far as I can understand (generally speaking, very little indeed...): could "flexibility" also stand for something else, like power or completeness of the scripting language. Is it so? Is Transcript such a good language?
nice chart, there! It seems that Revolution, falling right in the middle, is then the best choice! Sorry, I'm joking but still I think I agree with you.
(You forgot to mention Servoy...)
As far as I can understand (generally speaking, very little indeed...): could "flexibility" also stand for something else, like power or completeness of the scripting language. Is it so? Is Transcript such a good language?
Hmm. I think yes you could write something to either put the results into memory, or hidden fields or the like, but at some point you end up supporting 2 solutions to the same problem, at which point it might just be easier to store all of the data in the application itself. As far as the sql side, I'm still pretty ignorant too. Have done some stuff long ago in msql with php, as well as some with access, but only got deep enough to accomplish the goal. And this was about 11 years ago.
How much data are you talking about? If its not all that much, you can store it all in tables on a hidden card, or in arrays and bipass sql entirely, but this will make your applications needed resources larger. a database backend on the other hand, for a small number of records would probably be overkill
If you decided to go the table method could set it up very similarly to the description of the database schema above. 3 tables, ingredients, preperations, meals
Ingredients is simple, just a list of said ingredients.
To avoid having extra tables, the preperations table can contain something like "preperation name","directions for makin",1,4,23,53,43
Where the first item and 2nd item are always the name and the directions for creation (if thats where you're headed) the numbers would be the line number of the ingredient in the ingredient table.
Same for the meal table, but replacing the ingredient numbers with the line numbers of your preperations.
The problem with this is you must make sure that things don't change order in the tables, or all your line indexes become invalid.
There would certainly be some micromanagement required, but probably not any more difficult to implement than an sqlite backed app.
How much data are you talking about? If its not all that much, you can store it all in tables on a hidden card, or in arrays and bipass sql entirely, but this will make your applications needed resources larger. a database backend on the other hand, for a small number of records would probably be overkill
If you decided to go the table method could set it up very similarly to the description of the database schema above. 3 tables, ingredients, preperations, meals
Ingredients is simple, just a list of said ingredients.
To avoid having extra tables, the preperations table can contain something like "preperation name","directions for makin",1,4,23,53,43
Where the first item and 2nd item are always the name and the directions for creation (if thats where you're headed) the numbers would be the line number of the ingredient in the ingredient table.
Same for the meal table, but replacing the ingredient numbers with the line numbers of your preperations.
The problem with this is you must make sure that things don't change order in the tables, or all your line indexes become invalid.
There would certainly be some micromanagement required, but probably not any more difficult to implement than an sqlite backed app.
dartes wrote:hi Sturgis
thank you for the advice, I will work on it as soon as I have a little spare time.
But I still have a question (you will forgive my complete ignorance of sql): is it possible to save the results of sql queries? and could these results be referenced? If so I could keep a bunch of them, like virtual tables, for the 2nd and 3rd layer, and retrieve the data when necessary...
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...
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?
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...
by this you mean 1: storing in Rev cards and 2: storing in a database?you end up supporting 2 solutions to the same problem
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
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Middle could also mean mediocre. Or in this case it could just mean that the person making the chart has been working with Rev too long and has a Rev-centric perspective.dartes wrote:hi Richard
nice chart, there! It seems that Revolution, falling right in the middle, is then the best choice! Sorry, I'm joking but still I think I agree with you.
Hadn't heard of it before, but I'll check it out.dartes wrote:(You forgot to mention Servoy...)
Who can say what a "good" language is? Traveling that road requires defining things like "power" and "completeness". One of the turn-offs to some otherwise really good writings by folks like Sartre and Kierkegaard is that they spend an awful lot of time defining the meanings of words, and somewhere in all that the story gets hard to follow:)dartes wrote:As far as I can understand (generally speaking, very little indeed...): could "flexibility" also stand for something else, like power or completeness of the scripting language. Is it so? Is Transcript such a good language?
I'm no philosopher, just a humble toolmaker. I'll leave the epistemology to others; my specialty is task analysis. I really do like FMP and most other tools I've used. I use Rev a lot these days because it offers a satisfying blend of tradeoffs that favor the sort of work my clients need done.
Is it a good language? Often good enough for me.
But like my backpacking friends say, "Hike your own hike." Choose your own gear, move at your own pace, go where you want to go; just like where you are and enjoy the views.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Hi Dartes
From what you are saying you feel you have outgrown FM's facilities. Whilst Panorama (like Alpha 5) are positioning themselves in comparison to FM, I don't believe that Rev is doing that. Rev is more general than just a tool for creating a database and connecting a UI to that DB. For one thing, in Revolution there is more work for you to do to create a DB with a UI.
In a sense, one could consider Hypercard as more like FM, insofar as it uses a stack of cards as a data model. However, even Hypercard (which I never used) also had a focus on multimedia. Rev takes that focus further (hooking up with Quicktime on OS X and Windows). Rev also takes the database aspects of Hypercard further by permitting
But two other areas that I think distinguish Rev from these UI for DB tools is that Rev also links in to the underlying operating system (allowing one to open other programs and talk to them), and has the means to create quite 'low level' networking code. Historically Rev has also attempted to support an astonishingly large number of operating systems.
Revolution is a fairly generic programming environment, with a programming language more like Python or Ruby. Since Panorama also can embed these languages, then it would seem that at the programming level, they are quite similar in power. Another similarity between Panorama and Rev is that they both use in-RAM databases (although as you know, Rev is not just limited to those kinds of databases the way that Panorama appears to be). In terms of UI construction and multimedia, I think Rev is ahead of Panorama.
On to SQL. One thing to know about the many different databases (from SQLite, to MySQL, to Firebird, to DB2) is that they offer many different options, and SQL written for one will not necessarily work for another.
When you have written a SQL command you can save it, and you can have variables in the SQL command so that the same command can be used to retrieve different results. And when you talk of virtual tables, you can indeed construct views in SQL databases (another name for such views is "virtual table").
I had some recollection that FM could connect to SQL datasources, and it certainly appears to be true for FM 10 (http://www.filemaker.com/products/filem ... -data.html). As you know FM, I would suggest you take a look at some of the FM/SQL related stuff. That might be the best way for you to get an idea of what using a SQL database entails. Even though I scored 95% on the Oracle SQL exams a few years ago, I avoid SQL whenever I can. There are so many other ways to do things, and if you are really talking about a recipe database, then it sounds like overkill.
If you were to implement this in the simplest 'stack of cards' model of Revolution you would have a stack of meals (where each card was a different meal), a stack of intermediate ingredients (sauces), and a stack of basic ingredients. Assuming that one of your basic ingredients changed price (e.g. tomatoes), then when the price change took effect you would send a message to the intermediate cards to recalculate their prices, and the meals to recalculate their prices. (The event could be the other way round - when you go to view the card containing the pizza recipe, it could re-calculate it's price before showing you the card).
Incidentally, there is a 3rd party tool sold by RunRev that migrates FM databases into Rev applications (http://www.runrev.com/products/related- ... developer/). I haven't looked at it, but it might be of some interest to you. I believe you would end up with a Rev app as the front end and a SQL database as a back end. That may be instructive to you as to whether or not Rev has the facilities you want. There is a demo available (http://www.runrev.com/downloads/all-downloads/fmpro/).
I hope some of that is of use to you. If what I'm saying is obvious, please say so, then we can adjust the level of discussion appropriately.
From what you are saying you feel you have outgrown FM's facilities. Whilst Panorama (like Alpha 5) are positioning themselves in comparison to FM, I don't believe that Rev is doing that. Rev is more general than just a tool for creating a database and connecting a UI to that DB. For one thing, in Revolution there is more work for you to do to create a DB with a UI.
In a sense, one could consider Hypercard as more like FM, insofar as it uses a stack of cards as a data model. However, even Hypercard (which I never used) also had a focus on multimedia. Rev takes that focus further (hooking up with Quicktime on OS X and Windows). Rev also takes the database aspects of Hypercard further by permitting
But two other areas that I think distinguish Rev from these UI for DB tools is that Rev also links in to the underlying operating system (allowing one to open other programs and talk to them), and has the means to create quite 'low level' networking code. Historically Rev has also attempted to support an astonishingly large number of operating systems.
Revolution is a fairly generic programming environment, with a programming language more like Python or Ruby. Since Panorama also can embed these languages, then it would seem that at the programming level, they are quite similar in power. Another similarity between Panorama and Rev is that they both use in-RAM databases (although as you know, Rev is not just limited to those kinds of databases the way that Panorama appears to be). In terms of UI construction and multimedia, I think Rev is ahead of Panorama.
On to SQL. One thing to know about the many different databases (from SQLite, to MySQL, to Firebird, to DB2) is that they offer many different options, and SQL written for one will not necessarily work for another.
When you have written a SQL command you can save it, and you can have variables in the SQL command so that the same command can be used to retrieve different results. And when you talk of virtual tables, you can indeed construct views in SQL databases (another name for such views is "virtual table").
I had some recollection that FM could connect to SQL datasources, and it certainly appears to be true for FM 10 (http://www.filemaker.com/products/filem ... -data.html). As you know FM, I would suggest you take a look at some of the FM/SQL related stuff. That might be the best way for you to get an idea of what using a SQL database entails. Even though I scored 95% on the Oracle SQL exams a few years ago, I avoid SQL whenever I can. There are so many other ways to do things, and if you are really talking about a recipe database, then it sounds like overkill.
If you were to implement this in the simplest 'stack of cards' model of Revolution you would have a stack of meals (where each card was a different meal), a stack of intermediate ingredients (sauces), and a stack of basic ingredients. Assuming that one of your basic ingredients changed price (e.g. tomatoes), then when the price change took effect you would send a message to the intermediate cards to recalculate their prices, and the meals to recalculate their prices. (The event could be the other way round - when you go to view the card containing the pizza recipe, it could re-calculate it's price before showing you the card).
Incidentally, there is a 3rd party tool sold by RunRev that migrates FM databases into Rev applications (http://www.runrev.com/products/related- ... developer/). I haven't looked at it, but it might be of some interest to you. I believe you would end up with a Rev app as the front end and a SQL database as a back end. That may be instructive to you as to whether or not Rev has the facilities you want. There is a demo available (http://www.runrev.com/downloads/all-downloads/fmpro/).
I hope some of that is of use to you. If what I'm saying is obvious, please say so, then we can adjust the level of discussion appropriately.
yep, that was my joke. But I think you are also sticking to Rev for some good reason. Anyway I like it so much that I'm very prone in believing you or whoever says good things about it. I'm tired of researching (I could have also mentioned some other tools, like Omnis Studio, another great RAD). But you will be the first one to say: there is no "best of all".FourthWorld wrote:Middle could also mean mediocre. Or in this case it could just mean that the person making the chart has been working with Rev too long and has a Rev-centric perspective
Not that you may need it but it is a very interesting cross-platform tool (my best choice before stumbling on Rev). What I liked most is that it is entirely based on standards. No proprietary anything...FourthWorld wrote:Hadn't heard of it before, but I'll check it out
Wait, wait... I did not want to lead you on such a profound path about life, the universe and everything.FourthWorld wrote:Who can say what a "good" language is?... I'm no philosopher
I think it is possible to judge a language if you have used it enough. And you have, I guess.
You can speak a perfect French with just a couple hundreds words (no need of memorizing the entire French dictionary, 100000 or something) The dictionary is not meaningful even in the programmers world, I think, because you can find very powerful languages with million commands and still been able to accomplish just about everything with 1000.
We are talking about striking a balance, right? Ok then my question was: is Transcript powerful enough for accomplishing practically anything you can dream of?
FM developers have the same claim, that they can do whatever they wish. While this might be true (and I think it is true, I had a friend, a very good FM pro, who said so) the workaround necessary to reach the goal are sometime really too much (like building a house with a Swiss army knife). I'm sure you know the thing.
Anyway, thank you, thank you so very much for making this forum such a nice place (all of you).
I'm pretty decided to buy Rev now (I will just try to sell my 4D and Panorama licenses first).
Am I doing the right things? Yes, of course
Ah (sorry to bother so much): 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)?
Maybe I'm just too much database-concerned! I need to change perspective! Ok, I'm ready: so, who cares about tables, queries and the likes
