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
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
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
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
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?
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
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
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
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
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
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.
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
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
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 +
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
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
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
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
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
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
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
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
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
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
+ 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.
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
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
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
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
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
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,
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
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
33 matches
Mail list logo
