Re: Livecode = SQL?
On Fri, May 22, 2015 at 6:13 PM, Pierre Sahores s...@sahores-conseil.com wrote: Oh, I see what you mean. At the moment, I'm taking the approach of using a persistent server app, as the time to open a postgres database is significant, and could happen every couple or few seconds for each client. Should’t be at all. PostgreSQL works in a stateless mode. As long as each connection to PostgreSQL is : Maybe it's livecode then :) I think the last timing figures I had were a little under 100ms for revOpenDatabase() on localhost (a three or four year old quad-core i5 iMac) and around 250ms across town, with complex revDataFromQuery() (many insert/updates followed by a single query) taking something like a third as long e.g., put the milliseconds into strt put revDataFromQuery(,,5,dcmd) into theData put the milliseconds-strt into stp ck elapsed: stp (ck is a simple data writing handler) 1.- opened (by the client, the LC server or the persistant server) 2.- processed (the request) 3.- closed as soon as the expected data are returned PostgreSQL will be able to respond very smoothly to thousands of différent client requests peer second (lost more than Apache can provide it…). Apache as a bottleneck? :) On the other hand, if each connection is not closed as soon as the job is done, the main PostgreSQL controller will become less and less responsive because the unneeded still opened connections in its RAM array. Right now, what I'm writing is a persistent application running on the server, to which the remote client opens a socket and then writes to. On initial open, licensing is verified for the session, and some setup is done. Once initialized and authenticated, client uses write to socket to send it a command (inserts updates a query) with the changed data, and continues on. When the command is done, the server will write to the socket, and the client will make local updates. An http solution would be blocking, which would be bad in this context--these updates are written while the user is working (it actually waits until 2 seconds after the last keystroke), but any perceivable delay would be bad. The server can close the postgres connection when the socket closes. Also, I'm thinking that I may be able to drop the query--it's purpose is to find data updated by other users in nearly real time. Instead, with the socket staying open, the server could push data to every client using that table (not conceivably more than a handful), which would mean significantly less transactions (currently, client is checking every couple of seconds for updates) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Le 23 mai 2015 à 16:44, Dr. Hawkins doch...@gmail.com a écrit : On Fri, May 22, 2015 at 6:13 PM, Pierre Sahores s...@sahores-conseil.com wrote: Oh, I see what you mean. At the moment, I'm taking the approach of using a persistent server app, as the time to open a postgres database is significant, and could happen every couple or few seconds for each client. Should’t be at all. PostgreSQL works in a stateless mode. As long as each connection to PostgreSQL is : Maybe it's livecode then :) I think the last timing figures I had were a little under 100ms for revOpenDatabase() on localhost (a three or four year old quad-core i5 iMac) and around 250ms across town, with complex revDataFromQuery() (many insert/updates followed by a single query) taking something like a third as long e.g., put the milliseconds into strt put revDataFromQuery(,,5,dcmd) into theData put the milliseconds-strt into stp ck elapsed: stp (ck is a simple data writing handler) 1.- opened (by the client, the LC server or the persistant server) 2.- processed (the request) 3.- closed as soon as the expected data are returned PostgreSQL will be able to respond very smoothly to thousands of différent client requests peer second (lost more than Apache can provide it…). Apache as a bottleneck? Yes, it went for years and still is ! Have an eye to this, if needed : http://open.litespeedtech.com/mediawiki/ :) On the other hand, if each connection is not closed as soon as the job is done, the main PostgreSQL controller will become less and less responsive because the unneeded still opened connections in its RAM array. Right now, what I'm writing is a persistent application running on the server, to which the remote client opens a socket and then writes to. On initial open, licensing is verified for the session, and some setup is done. Once initialized and authenticated, client uses write to socket to send it a command (inserts updates a query) with the changed data, and continues on. When the command is done, the server will write to the socket, and the client will make local updates. A way i used for years but never in the exact same way you do. To secure against interlocking issues the runrev's application’s server running as a process in the background, i used the following way : Windows/MacOS native or Web browser clients - HTTP(S) - Apache - PHP sockets listener - TCP socket - Rev Application’s server - PostgreSQL Was 100% reliable in the early 2000 up to 800 connections peer seconds in running on a simple Linux P4 powered sever. You can have an eye on this at this old paper : http://www.sahores-conseil.com/insead/index_en.html An http solution would be blocking, Yes (in theory) and no (in practice) as long as each cgi thread opened by the http server (ideally openLiteSpeed instead of Apache 2) acts independently from each other. which would be bad in this context--these updates are written while the user is working (it actually waits until 2 seconds after the last keystroke), but any perceivable delay would be bad. The server can close the postgres connection when the socket closes. Also, I'm thinking that I may be able to drop the query--it's purpose is to find data updated by other users in nearly real time. Instead, with the socket staying open, the server could push data to every client using that table (not conceivably more than a handful), which would mean significantly less transactions (currently, client is checking every couple of seconds for updates) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On Sat, May 23, 2015 at 9:12 AM, Pierre Sahores s...@sahores-conseil.com wrote: An http solution would be blocking, Yes (in theory) and no (in practice) as long as each cgi thread opened by the http server (ideally openLiteSpeed instead of Apache 2) acts independently from each other. It would be blocking at the *client* end--the user app would have to wait for the http response, wouldn't it? Or is there a message-based way to do this? -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Le 23 mai 2015 à 18:20, Dr. Hawkins doch...@gmail.com a écrit : On Sat, May 23, 2015 at 9:12 AM, Pierre Sahores s...@sahores-conseil.com wrote: An http solution would be blocking, Yes (in theory) and no (in practice) as long as each cgi thread opened by the http server (ideally openLiteSpeed instead of Apache 2) acts independently from each other. It would be blocking at the *client* end--the user app would have to wait for the http response, wouldn't it? Yes, it blocks until the HTTP POST reply comes back as the it variable (for just some ticks as long as the server-side stuff is perfectly tuned). Or is there a message-based way to do this? Did’t never, for my own, need to go in this way in about client - server - databases based information systems. Note : in about such kind of systems, as pure functional languages, LiveCode and Scala (Polytechnic School of Lausanne) will always respond faster than any other server-side based solutions (PHP5, Java7/8, etc…) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Le 23 mai 2015 à 02:30, Dr. Hawkins doch...@gmail.com a écrit : On Thu, May 21, 2015 at 7:58 PM, Pierre Sahores s...@sahores-conseil.com wrote: I'm not sure what you're saying here--I'm assuming a central server being hit by clients around the country, wo how can locahost handle that? The remote client - HTTPS - Apache - (LC-Server - PostgreSQL, both those two last components connected trough port 5432 on the 127.0.0.1 localhost IP address) Oh, I see what you mean. At the moment, I'm taking the approach of using a persistent server app, as the time to open a postgres database is significant, and could happen every couple or few seconds for each client. Should’t be at all. PostgreSQL works in a stateless mode. As long as each connection to PostgreSQL is : 1.- opened (by the client, the LC server or the persistant server) 2.- processed (the request) 3.- closed as soon as the expected data are returned PostgreSQL will be able to respond very smoothly to thousands of différent client requests peer second (lost more than Apache can provide it…). On the other hand, if each connection is not closed as soon as the job is done, the main PostgreSQL controller will become less and less responsive because the unneeded still opened connections in its RAM array. However, postgres itself supports SSL, and can enforce SSL only--but livecode doesn't support this. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On Thu, May 21, 2015 at 7:58 PM, Pierre Sahores s...@sahores-conseil.com wrote: I'm not sure what you're saying here--I'm assuming a central server being hit by clients around the country, wo how can locahost handle that? The remote client - HTTPS - Apache - (LC-Server - PostgreSQL, both those two last components connected trough port 5432 on the 127.0.0.1 localhost IP address) Oh, I see what you mean. At the moment, I'm taking the approach of using a persistent server app, as the time to open a postgres database is significant, and could happen every couple or few seconds for each client. However, postgres itself supports SSL, and can enforce SSL only--but livecode doesn't support this. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On Sun, May 17, 2015 at 3:57 PM, Pierre Sahores s...@sahores-conseil.com wrote: Le 18 mai 2015 à 00:23, Dr. Hawkins doch...@gmail.com a écrit : There are definitely a couple of *whopping* holes: * cannot connect securely to Postgres Why don’t you access it in localhost mode only (via lc server + script/stack lib). I do this all the time to store incoming HTTPS POST data. It’s, as long as i know, the most reliable way to go in about server’s security task. I'm not sure what you're saying here--I'm assuming a central server being hit by clients around the country, wo how can locahost handle that? * cannot submit multi-line queries to mySQL Did’t try myself at this point under MariaDB/MySQL (and i will do soon as i’m on the way to move some of my apps from PG to MariaDB) but this works perfectly fine against PostgreSQL. That's the problem--I trried to use mySQL as a temporary replacement until I have my server working, but the compound commands I've been using with postgres and mySQL bomb. In another thread, it was mentioned that there is work to make livecode handle multiline mySQL, but it isn't there now. And in my googling, the top hits were from when I asked the question a couple of years ago . . . These are both drop-dead showstoppers. There are also conditions in whichrevdberr, is returned after successful transactions. I believe this applies to both both post postgres and SQLite Never had to deal with this « revdberr » glitchy until yet, at least against my LC-Server+PostgreSQL server's apps. if you use revDataFromQuery() and postgres, in a couple of circumstances (I believe INSERT is one of them), this is the message returned on a successful operation. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Le 22 mai 2015 à 03:47, Dr. Hawkins doch...@gmail.com a écrit : On Sun, May 17, 2015 at 3:57 PM, Pierre Sahores s...@sahores-conseil.com wrote: Le 18 mai 2015 à 00:23, Dr. Hawkins doch...@gmail.com a écrit : There are definitely a couple of *whopping* holes: * cannot connect securely to Postgres Why don’t you access it in localhost mode only (via lc server + script/stack lib). I do this all the time to store incoming HTTPS POST data. It’s, as long as i know, the most reliable way to go in about server’s security task. I'm not sure what you're saying here--I'm assuming a central server being hit by clients around the country, wo how can locahost handle that? The remote client - HTTPS - Apache - (LC-Server - PostgreSQL, both those two last components connected trough port 5432 on the 127.0.0.1 localhost IP address) * cannot submit multi-line queries to mySQL Did’t try myself at this point under MariaDB/MySQL (and i will do soon as i’m on the way to move some of my apps from PG to MariaDB) but this works perfectly fine against PostgreSQL. That's the problem--I trried to use mySQL as a temporary replacement until I have my server working, but the compound commands I've been using with postgres and mySQL bomb. Agreed ! MariaDB is too permissive, even in using the INNODB engine... In another thread, it was mentioned that there is work to make livecode handle multiline mySQL, but it isn't there now. Confirmed. Just tested this today and did’t find any way to go at this point. Will try with shell or curl and report there if something can do the job. revDB don’t seems to be able to handle this at all. And in my googling, the top hits were from when I asked the question a couple of years ago . . . These are both drop-dead showstoppers. There are also conditions in whichrevdberr, is returned after successful transactions. I believe this applies to both both post postgres and SQLite Never had to deal with this « revdberr » glitchy until yet, at least against my LC-Server+PostgreSQL server's apps. if you use revDataFromQuery() and postgres, in a couple of circumstances (I believe INSERT is one of them), this is the message returned on a successful operation. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On 18.05.2015 at 21:11 Uhr -0600 Mike Bonner apparently wrote: With lc server, to do the resident thing, session control should work, storing current data to the session variables which can then be used in further calls (server side) This way you don't have to send the same repeating data to the server every time, you can pull what you need from the local server session and use it in your .lc scripts. If I'm completely misunderstanding what you wish to do, of course ignore this. Session-specific data is not an issue. The concern is not sending the data to the server. That comes in small chunks only. The concern is the data that the server needs to display the pages for users. That data transcends the sessions, meaning that it is the same for all users, although different users use different subsets of that data. In my current setup, I fetch that data into global arrays when loading the program. By keeping that data resident, I reduce the number of calls to the database by half and in some cases up to 75%. That setup is quite old, however, and I want to upgrade it. Maybe calls to the database are not as expensive on newer systems and nothing to worry about. RObert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Hi Robert, Still works but purely outdated. It was before LC-Server came out and i warmly recommend to use it instead of my old fashion « PHP listener + Metacard/Rev stacks » way to go. Best, Pierre Le 18 mai 2015 à 15:39, Robert Brenstein r...@robelko.com a écrit : On 18.05.2015 at 0:57 Uhr +0200 Pierre Sahores apparently wrote: Why don't you access it in localhost mode only (via lc server + script/stack lib). I do this all the time to store incoming HTTPS POST data. It's, as long as i know, the most reliable way to go in about server's security task. Pierre, are you planning to update your http://www.sahores-conseil.com/insead/index_en.html pages for the current products? Or do they still work? RObert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On 18.05.2015 at 0:57 Uhr +0200 Pierre Sahores apparently wrote: Why don't you access it in localhost mode only (via lc server + script/stack lib). I do this all the time to store incoming HTTPS POST data. It's, as long as i know, the most reliable way to go in about server's security task. Pierre, are you planning to update your http://www.sahores-conseil.com/insead/index_en.html pages for the current products? Or do they still work? RObert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On 18.05.2015 at 16:03 Uhr +0200 Pierre Sahores apparently wrote: Hi Robert, Still works but purely outdated. It was before LC-Server came out and i warmly recommend to use it instead of my old fashion « PHP listener + Metacard/Rev stacks » way to go. Best, Pierre I haven't got into the LC-Server game yet, but it seems to be that the server stacks are not staying resident. My application will require lot of pre-loading of various stuff (from a db as well as disk files) that stays the same for all user calls. Are you saying that this is of no concern anymore? RObert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Robert Brenstein wrote: Still works but purely outdated. It was before LC-Server came out and i warmly recommend to use it instead of my old fashion « PHP listener + Metacard/Rev stacks » way to go. I haven't got into the LC-Server game yet, but it seems to be that the server stacks are not staying resident. My application will require lot of pre-loading of various stuff (from a db as well as disk files) that stays the same for all user calls. Are you saying that this is of no concern anymore? With any CGI nothing stays resident, whether Perl, PHP, Python, or LiveCode. CGIs are command-line apps called by Apache to handle certain requests, and they're born, live, and die in the time it takes to return data to stdout so Apache can return it to the client. One way to have resident resources would be FastCGI, in which the process is loaded once and forks child processes for incoming requests in a way that passes off the connection to each child. PHP offers a forking compile, but at this time the LiveCode engine doesn't fork (though there's some interest in the community to make a version that does down the road). In most cases straight CGI is sufficient for reasonable traffic, depending of course on the complexity of the CGI app itself. For many years until just this last summer the default configuration for PHP on Dreamhost was simple CGI. For higher traffic loads a forkable engine like PHP can be used under FastCGI, or if you need to use LiveCode with high-traffic requirements and are using a dedicated server or VPS you can write your own daemon to handle requests for specific application needs, feeding a pool of child workers for surprisingly good throughput using what we have today. If writing a custom application server from scratch seems a bit more than you'd care to take on for your project, you may be pleasantly surprised by how well LiveCode performs under CGI for most reasonable traffic loads. Comparing a custom search engine I wrote for a project in LC to a Drupal install on the same server running under PHP, our search engine was able to parse the incoming expression, dive into several index files, obtain the results, rank them, wrap them in HTML, and hand them back to Apache in 1/5th the amount of CPU time Drupal required to just load a page, and 1/3 the memory. Performance can be improved even further by being mindful of what a friend calls going to TOWN - Touch Only What's Needed. In the short lifecycle of a CGI app time is precious, so it helps to make sure you're only obtaining the data you'll actually use, and in a form well optimized for accessing. For example, in some cases the time it takes to run a stored array file through arrayDecode can be much longer than just using a delimited file with lineoffset (lots of specifics at play there, so benchmark your specific algos first). RevIgniter is a very good example of LiveCode Server used well. It performs admirably, while making extensive use of many files and even database connections, all withing the CGI lifecycle. Besides, with the efficiency of Linux RAM caching you're rarely actually reading files from disk. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Le 18 mai 2015 à 17:31, Robert Brenstein r...@robelko.com a écrit : On 18.05.2015 at 16:03 Uhr +0200 Pierre Sahores apparently wrote: Hi Robert, Still works but purely outdated. It was before LC-Server came out and i warmly recommend to use it instead of my old fashion « PHP listener + Metacard/Rev stacks » way to go. Best, Pierre I haven't got into the LC-Server game yet, but it seems to be that the server stacks are not staying resident. No. You are true on this. My application will require lot of pre-loading of various stuff (from a db as well as disk files) that stays the same for all user calls. My old fashion « PHP listener + Metacard/Rev stacks » permits this. Are you saying that this is of no concern anymore? In my experience, persistence data reliability and RAM are not the best friends each time we have to deal, on the other hand, with massive concurrent accesses in write mode. It’s the main concern making CGI mode* + RDBMS lots more reliable. * the way most of the big applications servers are using, including some special improvements related to data caching management : previous responses stored in hash table can be directly accessed without new SQL call. Java, PHP, Perl, LC-Server supports to be configured in this way. Note : PostgreSQL went always my ACID-RDBMS of choice but i have to admit that it’s not always the simplest platform to tune in certain situations. In the mean time, the MariaDB 10.xx (open source version of MySQL) seems to be becoming a very reliable platform too (INNOdb engine) lots more trustable than MySQL used to be in the past (v. 3 and 4). Best Regards, Pierre RObert ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On 5/18/2015 11:23 AM, Richard Gaskin wrote: you may be pleasantly surprised by how well LiveCode performs under CGI for most reasonable traffic loads. Somewhere in my archives I have a note that says LC CGIs work fine with 5,000 hits per second. It undoubtedly depends on what the script does, and I don't think the script was tested with more hits than that, so it isn't necessarily either a top limit or a guarantee. But it does show that LC is pretty fast responding to CGI requests. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
With lc server, to do the resident thing, session control should work, storing current data to the session variables which can then be used in further calls (server side) This way you don't have to send the same repeating data to the server every time, you can pull what you need from the local server session and use it in your .lc scripts. If I'm completely misunderstanding what you wish to do, of course ignore this. On Mon, May 18, 2015 at 12:30 PM, J. Landman Gay jac...@hyperactivesw.com wrote: On 5/18/2015 11:23 AM, Richard Gaskin wrote: you may be pleasantly surprised by how well LiveCode performs under CGI for most reasonable traffic loads. Somewhere in my archives I have a note that says LC CGIs work fine with 5,000 hits per second. It undoubtedly depends on what the script does, and I don't think the script was tested with more hits than that, so it isn't necessarily either a top limit or a guarantee. But it does show that LC is pretty fast responding to CGI requests. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Livecode = SQL?
To close, I am really, really looking forward to getting my hands on Pete's SQL Magic. He teased us with it at RunRev this last year and more than ready to start playing with it. Something to look forward to in the near future. Ill try pitching someone else's product :-) Oreilly SQL Pocket Guide is a handy little reference and you can usually find it for less than $10 if you shop around: http://shop.oreilly.com/product/0636920013471.do Best, Lynn ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Hi Eric - meet SQL Yoga http://www.bluemangolearning.com/livecode/software/libraries/sql-yoga/ - The difference between genius and stupidity is; genius has its limits. - Albert Einstein -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Livecode-SQL-tp4692413p4692415.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Le 18 mai 2015 à 00:23, Dr. Hawkins doch...@gmail.com a écrit : On Sunday, May 17, 2015, Pierre Sahores s...@sahores-conseil.com wrote: I never understood some discussions about the urgent need of their improvement. They just works as fine as our SQL queries well build are (complex inner joints support, etc…). There are definitely a couple of *whopping* holes: * cannot connect securely to Postgres Why don’t you access it in localhost mode only (via lc server + script/stack lib). I do this all the time to store incoming HTTPS POST data. It’s, as long as i know, the most reliable way to go in about server’s security task. * cannot submit multi-line queries to mySQL Did’t try myself at this point under MariaDB/MySQL (and i will do soon as i’m on the way to move some of my apps from PG to MariaDB) but this works perfectly fine against PostgreSQL. These are both drop-dead showstoppers. There are also conditions in whichrevdberr, is returned after successful transactions. I believe this applies to both both post postgres and SQLite Never had to deal with this « revdberr » glitchy until yet, at least against my LC-Server+PostgreSQL server's apps. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Skip is absolutely correct - if you have the head-space then it's well worth learning SQL Skip Kimpel wrote If you plan on doing any type of database projects in the future, do yourself a favor and learn SQL. Extremely powerful when combined with LC! - The difference between genius and stupidity is; genius has its limits. - Albert Einstein -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Livecode-SQL-tp4692413p4692425.html Sent from the Revolution - User mailing list archive at Nabble.com. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Everybody that has responded to this thread that are pitching their products, let me clarify back to Eric that knowledge of SQL is important to if you want to make the impossible, possible. The sky is the limit when you have full knowledge of SQL and take advantage of its server side scripting and other server based features. HOWEVER, I think I own every one of the products mentioned for sale and I use them ALL... Each tool has its own unique advantages and purposes. I am, by no means, suggesting bypassing the thought of purchasing any of these. To close, I am really, really looking forward to getting my hands on Pete's SQL Magic. He teased us with it at RunRev this last year and more than ready to start playing with it. Something to look forward to in the near future. SKIP KIMPEL On Sun, May 17, 2015 at 10:12 PM, Lynn Fredricks lfredri...@proactive-intl.com wrote: If you plan on doing any type of database projects in the future, do yourself a favor and learn SQL. Extremely powerful when combined with LC! I also have to agree with this. Our Valentina DB can use SQL as well. SQL is not hard to learn. But...also a plug. Our Valentina Studio Pro has an easy SQL Builder in it for building SQL scripts. You can test drive this in the free version. We've learned to live with the fact that lots of people love SQLite (well, it took Ruslan a little longer than me ;-)). Our next version of Valentina Server can accept a SQLite database, allowing you to serve SQLite with the advantage of our network handling features of our server. And yeah, the 5 connection version you can try out for free yourself (and its got reports too!). Best regards, Lynn Fredricks Paradigma Software http://www.paradigmasoft.com Valentina SQL Server: The Ultra-fast, Royalty Free Database Server ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
RE: Livecode = SQL?
If you plan on doing any type of database projects in the future, do yourself a favor and learn SQL. Extremely powerful when combined with LC! I also have to agree with this. Our Valentina DB can use SQL as well. SQL is not hard to learn. But...also a plug. Our Valentina Studio Pro has an easy SQL Builder in it for building SQL scripts. You can test drive this in the free version. We've learned to live with the fact that lots of people love SQLite (well, it took Ruslan a little longer than me ;-)). Our next version of Valentina Server can accept a SQLite database, allowing you to serve SQLite with the advantage of our network handling features of our server. And yeah, the 5 connection version you can try out for free yourself (and its got reports too!). Best regards, Lynn Fredricks Paradigma Software http://www.paradigmasoft.com Valentina SQL Server: The Ultra-fast, Royalty Free Database Server ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
On Sunday, May 17, 2015, Pierre Sahores s...@sahores-conseil.com wrote: I never understood some discussions about the urgent need of their improvement. They just works as fine as our SQL queries well build are (complex inner joints support, etc…). There are definitely a couple of *whopping* holes: * cannot connect securely to Postgres * cannot submit multi-line queries to mySQL These are both drop-dead showstoppers. There are also conditions in whichrevdberr, is returned after successful transactions. I believe this applies to both both post postgres and SQLite -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
+ 1 and the standard revdb libs are the most suitable API for any advanced db interactions with both PostgreSQL, MariaDB/MySQL and SQLite. With some care, it will works very well too against any Oracle db = v. 7.3. I never understood some discussions about the urgent need of their improvement. They just works as fine as our SQL queries well build are (complex inner joints support, etc…). I would't forget to add that revdb is the fastest db API available for Livecode ;D Le 17 mai 2015 à 21:02, Skip Kimpel skiplon...@gmail.com a écrit : If you plan on doing any type of database projects in the future, do yourself a favor and learn SQL. Extremely powerful when combined with LC! SKIP On May 17, 2015, at 2:37 PM, Michael Gruenthal mgruent...@mac.com wrote: Take a look at Andre Garzia¹s dbLib at http://andregarzia.com/pages/en/dblib/ He doesn¹t seem to be actively developing it anymore, but it works. On 5/17/15, 12:03 PM, Eric A. Engle engleer...@yahoo.com wrote: Ugh. I am learning SQL. It is ugly. I am hoping someone has a stack which could convert livecode statements into SQL queries. It would save me having to learn syntax. Any thoughts are appreciated. Thank you. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Pierre Sahores mobile : 06 03 95 77 70 www.sahores-conseil.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
At this point, I have to give a shameless plug to my soon-to-be-released product, SQLMagic. If I were a marketing person, I'd probably come up with a slogan something like SQLmagic, it makes your code disappear, but I'm not so I won't but it does :-) Take a look at the video at the bottom of http://www.lcsql.com/sqlmagic.html to get a flavor for how it works. It shows how to create a three-table inquiry transaction complete with search capabilities in a few minutes without writing any Livecode scripts or figuring out any SQL statements. It's equally easy to create Insert, Update, and Delete processing, even mixing processing modes within one transaction. SQLMagic takes care of all the SQL statements, data conversion, locking, and navigation between tables. Please contact me off list if you are interested in what you see. I will be on vacation for a couple of weeks but plan to go into full beta mode when I return at the beginning of June. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Sun, May 17, 2015 at 12:02 PM, Skip Kimpel skiplon...@gmail.com wrote: If you plan on doing any type of database projects in the future, do yourself a favor and learn SQL. Extremely powerful when combined with LC! SKIP On May 17, 2015, at 2:37 PM, Michael Gruenthal mgruent...@mac.com wrote: Take a look at Andre Garzia¹s dbLib at http://andregarzia.com/pages/en/dblib/ He doesn¹t seem to be actively developing it anymore, but it works. On 5/17/15, 12:03 PM, Eric A. Engle engleer...@yahoo.com wrote: Ugh. I am learning SQL. It is ugly. I am hoping someone has a stack which could convert livecode statements into SQL queries. It would save me having to learn syntax. Any thoughts are appreciated. Thank you. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
If you plan on doing any type of database projects in the future, do yourself a favor and learn SQL. Extremely powerful when combined with LC! SKIP On May 17, 2015, at 2:37 PM, Michael Gruenthal mgruent...@mac.com wrote: Take a look at Andre Garzia¹s dbLib at http://andregarzia.com/pages/en/dblib/ He doesn¹t seem to be actively developing it anymore, but it works. On 5/17/15, 12:03 PM, Eric A. Engle engleer...@yahoo.com wrote: Ugh. I am learning SQL. It is ugly. I am hoping someone has a stack which could convert livecode statements into SQL queries. It would save me having to learn syntax. Any thoughts are appreciated. Thank you. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Livecode = SQL?
Take a look at Andre Garzia¹s dbLib at http://andregarzia.com/pages/en/dblib/ He doesn¹t seem to be actively developing it anymore, but it works. On 5/17/15, 12:03 PM, Eric A. Engle engleer...@yahoo.com wrote: Ugh. I am learning SQL. It is ugly. I am hoping someone has a stack which could convert livecode statements into SQL queries. It would save me having to learn syntax. Any thoughts are appreciated. Thank you. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: LiveCode SQL APIs
I'm not a experienced sql - lc connection maker either, but i ask myself why to keep a connection alive? So I take the freedom to append my own question to yours: Some people like to keep alive their DB connections. But isn't it usually a more robust approach to close the connection as soon as the query is handled? I've found it useful to handle mass-writes slightly differently, but there is normally so much happening, that the DB connection doesn't really idle at all. On 14 Feb 2011, at 23:38, Paul Dupuis wrote: I can think a few way to construct a keep-alive process to ensure that a connection to a MySQL database via the LiveCode database drivers doesn't time out. However, it occurs to me that folks who spend more time writing LiveCode MySQL applications than I may have come up with a best way to keep the connection from timing out, so I thought I would ask the list. An idle loop would do it, but using idle is not a best approach. Any best approaches out there that someone cares to share? Thanks! -- Paul Dupuis Cofounder Researchware, Inc. http://www.researchware.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: LiveCode SQL APIs
Björnke, In other languages, in days gone by, it was good practice to keep the connection open if an application expected to issue multiple queries (such as a user driven reporting application) becuase there was overhead in setting up a connection and creating and opening a connection, executing a query, and closing a connection for each query could impact performance. With the speed of today's servers, databases, clients, networks, and LiveCode, I am not sure connection maintenance for performance has any noticeable impact. I am also interested because, even though I have tried to thoroughly trap for connection timeout error and execute code to reconnect, i still get connection has gone away errors every now and then. Instead of revising all my error raping code again, I am considering code for maintaining a persistent connection. On 2/14/2011 5:44 PM, Björnke von Gierke wrote: I'm not a experienced sql - lc connection maker either, but i ask myself why to keep a connection alive? So I take the freedom to append my own question to yours: Some people like to keep alive their DB connections. But isn't it usually a more robust approach to close the connection as soon as the query is handled? I've found it useful to handle mass-writes slightly differently, but there is normally so much happening, that the DB connection doesn't really idle at all. On 14 Feb 2011, at 23:38, Paul Dupuis wrote: I can think a few way to construct a keep-alive process to ensure that a connection to a MySQL database via the LiveCode database drivers doesn't time out. However, it occurs to me that folks who spend more time writing LiveCode MySQL applications than I may have come up with a best way to keep the connection from timing out, so I thought I would ask the list. An idle loop would do it, but using idle is not a best approach. Any best approaches out there that someone cares to share? Thanks! -- Paul Dupuis Cofounder Researchware, Inc. http://www.researchware.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Paul Dupuis Cofounder Researchware, Inc. http://www.researchware.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: LiveCode SQL APIs
It is my experience that when connecting to web based SQL servers, that they drop you themselves after a period of idle time. This is of course, to prevent someone from running a kind of DDOS on your SQL server. Unless you control the server, you cannot disable this. I agree with the assessment that you should open the database connection, do your business, and get out. Some will say you shouldn't even be connecting directly to an SQL server over the internet, but that point has been hashed and rehashed before so I won't re-rehash it here. Bob On Feb 14, 2011, at 2:38 PM, Paul Dupuis wrote: I can think a few way to construct a keep-alive process to ensure that a connection to a MySQL database via the LiveCode database drivers doesn't time out. However, it occurs to me that folks who spend more time writing LiveCode MySQL applications than I may have come up with a best way to keep the connection from timing out, so I thought I would ask the list. An idle loop would do it, but using idle is not a best approach. Any best approaches out there that someone cares to share? Thanks! -- Paul Dupuis Cofounder Researchware, Inc. http://www.researchware.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: LiveCode SQL APIs
If you have multiple users for your db, you will not want persistent connections because there's a limit to how many simultaneous connections you can have to a MySQL db. On Feb 14, 2011, at 3:08 PM, Paul Dupuis p...@researchware.com wrote: Björnke, In other languages, in days gone by, it was good practice to keep the connection open if an application expected to issue multiple queries (such as a user driven reporting application) becuase there was overhead in setting up a connection and creating and opening a connection, executing a query, and closing a connection for each query could impact performance. With the speed of today's servers, databases, clients, networks, and LiveCode, I am not sure connection maintenance for performance has any noticeable impact. I am also interested because, even though I have tried to thoroughly trap for connection timeout error and execute code to reconnect, i still get connection has gone away errors every now and then. Instead of revising all my error raping code again, I am considering code for maintaining a persistent connection. On 2/14/2011 5:44 PM, Björnke von Gierke wrote: I'm not a experienced sql - lc connection maker either, but i ask myself why to keep a connection alive? So I take the freedom to append my own question to yours: Some people like to keep alive their DB connections. But isn't it usually a more robust approach to close the connection as soon as the query is handled? I've found it useful to handle mass-writes slightly differently, but there is normally so much happening, that the DB connection doesn't really idle at all. On 14 Feb 2011, at 23:38, Paul Dupuis wrote: I can think a few way to construct a keep-alive process to ensure that a connection to a MySQL database via the LiveCode database drivers doesn't time out. However, it occurs to me that folks who spend more time writing LiveCode MySQL applications than I may have come up with a best way to keep the connection from timing out, so I thought I would ask the list. An idle loop would do it, but using idle is not a best approach. Any best approaches out there that someone cares to share? Thanks! -- Paul Dupuis Cofounder Researchware, Inc. http://www.researchware.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode -- Paul Dupuis Cofounder Researchware, Inc. http://www.researchware.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
