On Thu, Apr 7, 2016 at 5:04 PM, Mark Wieder wrote:
> Kids... don't try this at home...
Err, yes.
One of the reasons I made no effort to insure that it was correct!
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-li
Gave that a whirl with col4=? and a bind parameter of "*" OR 1=1 for it and
it returned no data. Pretty sure it takes the whole string as a search
value for col4.
On Thu, Apr 7, 2016 at 7:19 PM Mark Wieder wrote:
> On 04/07/2016 06:41 PM, Peter Haworth wrote:
> > Right, I think I have that co
On 04/07/2016 06:41 PM, Peter Haworth wrote:
Right, I think I have that covered since I prepare and bind the data in
separate steps using the php functions for those purposes.
So instead of assembling a SELECT statement like this:
SELECT col1,col2,col3 FROM table WHERE col4=''
... and then exe
Right, I think I have that covered since I prepare and bind the data in
separate steps using the php functions for those purposes.
So instead of assembling a SELECT statement like this:
SELECT col1,col2,col3 FROM table WHERE col4=''
... and then executing it directly, I prepare this statement:
On 04/07/2016 04:31 PM, Dr. Hawkins wrote:
I've probably hacked up the syntax, and there might be an intermediate
query needed to get the table name, but something like this grabs all your
data and deletes it while you thought you were doing an INSERT or such.
Kids... don't try this at home...
On Wed, Apr 6, 2016 at 1:03 PM, Peter Haworth wrote:
> Now you've got me worried! I had the impression that since the php scripts
> run on my server and access the mySQL database on the same server, there
> wouldn't be any sql injection issues, particularly since I never send any
> SQL statement
Peter:
Glad my stack was a help. Be careful with my mySQL php scripts. The examples
are meant only as starting points. They allow for injection attacks if the
inputs aren’t carefully filtered in Livecode before being formed into the
query. You could modify the php so that each script does only a
On 04/06/2016 02:12 PM, Peter Haworth wrote:
I just can't be bothered replying to that...
On Wed, Apr 6, 2016 at 1:55 PM Mark Wieder wrote:
On 04/06/2016 01:03 PM, Peter Haworth wrote:
I'm just as lazy as the next developer
Oh, I could probably give you a run for your money in the lazy ra
I just can't be bothered replying to that...
On Wed, Apr 6, 2016 at 1:55 PM Mark Wieder wrote:
> On 04/06/2016 01:03 PM, Peter Haworth wrote:
>
> > I'm just as lazy as the next developer
>
> Oh, I could probably give you a run for your money in the lazy race any
> day.
>
> --
> Mark Wieder
>
On 04/06/2016 01:03 PM, Peter Haworth wrote:
I'm just as lazy as the next developer
Oh, I could probably give you a run for your money in the lazy race any
day.
--
Mark Wieder
ahsoftw...@gmail.com
___
use-livecode mailing list
use-livecode@lis
Hi Mark,
Now you've got me worried! I had the impression that since the php scripts
run on my server and access the mySQL database on the same server, there
wouldn't be any sql injection issues, particularly since I never send any
SQL statements from my client app to the server.
I'm just as lazy
This is where it gets interesting. My original plan was to directly
connect to mySQL from Livecode using the variableslist parameter to the
various Livecode db functions, which should protect against sql injection.
To be honest, I don't recall why I went away from that plan in favor of
middleware.
On 04/06/2016 10:35 AM, Ray wrote:
Yeah, my expectation is that we'll avoid injection issues using the PHP
middleware.
No, sql injection is avoided by proper coding and by paying attention.
PHP as a platform is notoriously subject to sql injection errors mostly
because its ease of use encour
I do remember a post from you about not being able to send multiple
statements to SQL in one Livecode call, and also I'm pretty sure it was
confirmed. so that's probably what you're thinking of.
On Wed, Apr 6, 2016 at 10:17 AM Dr. Hawkins wrote:
> On Wed, Apr 6, 2016 at 9:42 AM, Peter Haworth
Very interesting. I've looked a little into postgreSQL, not that much.
I think we've pretty much decided to stick with mySQL for now, it should
work for our purpose, but you've peaked my interest in postgreSQL.
Many thanks for your input on this Richard!
On 4/6/2016 3:13 PM, Dr. Hawkins wrot
I'd actually be happy with emails if they included everything I need and
excluded unnecessary stuff, but we've had a lot of problems in the past
relying on general emails so we're going to try something which should
help guide our users to writing good bug reports.
On 4/6/2016 2:55 PM, EED-wp
On Wed, Apr 6, 2016 at 10:38 AM, Ray wrote:
> So Richard, what did you end up going with when neither sqLite nor mySQL
> worked out for you?
postgreSQL
It's more mature in some ways than mySQL, but more importantly, I can give
compound transaction (there's a 500+ statement query on client open
Ray
Good idea. I just get bug reports emailed to me. That's why I send the email by
accessing a php mail system on my server. That way the user doesn't have to
have email installed.
William Prothero
http://ed.earthednet.org
> On Apr 6, 2016, at 8:32 AM, Ray wrote:
>
> Richard - thanks for th
I haven't gotten that far into the database syntax and Livecode's
handling of it yet so I couldn't say, yet. But I'm sure I'll figure out
soon what, if any, Livecode's limitations are.
So Richard, what did you end up going with when neither sqLite nor mySQL
worked out for you?
On 4/6/2016
Yeah, my expectation is that we'll avoid injection issues using the PHP
middleware.
All in all, it seems like a pretty common need; to store on a server a
database that multiple users are going to be updating. I wish there
were some sort of a Livecode lesson which detailed several approaches
On Wed, Apr 6, 2016 at 9:42 AM, Peter Haworth wrote:
>
> mySQL does have transactions, as do all SQL implementations. They're part
> of the SQL spec. postGresql may well have advantages over mySQL but that
> isn't one of them.
>
Now I'm trying to remember: is it that livecdoe that can't succes
On Wed, Apr 6, 2016 at 8:32 AM, Ray wrote:
> Richard - thanks for this advice. It's really quite helpful. We've
> abandoned the sqLite idea but I think mySQL should work fine. The purpose
> of this database is to maintain an index of bug reports. The bug reports
> themselves are actually Livec
Hi Ray,
Lots of things for you to think about! As someone else mentioned, I
thought you were using a network file system rather than a web server.
Just to set the record straight on a couple of things.
mySQL does have transactions, as do all SQL implementations. They're part
of the SQL spec. p
Richard - thanks for this advice. It's really quite helpful. We've
abandoned the sqLite idea but I think mySQL should work fine. The
purpose of this database is to maintain an index of bug reports. The bug
reports themselves are actually Livecode stacks. The database will
serve as an index
On Wed, Apr 6, 2016 at 6:05 AM, Ray wrote:
> I thought of downloading it, updating it, and then putting it back on the
> server but that wouldn't work if two users simultaneously did so. Since
> I'll have many users using the database simultaneously everything has to be
> done on the server. I
Bill thanks for sharing this with me. I've downloaded it and I'm
looking into now. I'll let you know how it works out.
On 4/6/2016 10:26 AM, Earthednet-wp wrote:
Ray,
I have a stack for MySQL implementation that might help you get started, since
you are thinking of using php as middleware. I
Ray,
I have a stack for MySQL implementation that might help you get started, since
you are thinking of using php as middleware. It's at
http://es.earthednet.org/SoftwareForEducation
Scroll to the bottom of the page.
Good luck.
Bill
William Prothero
http://es.earthednet.org
> On Apr 6, 2016, at
Thanks for your confirmation on this, Mike. We'll continue with the PHP
middleware plan. It seems to be industry standard and it makes sense,
especially from a security standpoint.
On 4/6/2016 10:15 AM, Mike Bonner wrote:
Actually, you CAN connect directly to to mysql server (its actually a
Thanks Mike. I've used Andre's solutions a number of times and they've
always worked really well. I wasn't aware of this one.
On 4/6/2016 10:21 AM, Mike Bonner wrote:
On an "LC server" side note, andre garzias dblib is really helpful. It
might be possible to build up your query locally using
On an "LC server" side note, andre garzias dblib is really helpful. It
might be possible to build up your query locally using dblib, then send the
resulting array to the server that also uses dblib, set the array there and
execute the action. (dblib works great) I think it will work with either
Actually, you CAN connect directly to to mysql server (its actually a
server in its own right) if you set things up that way. You have to change
where connections are allowed from but honestly, you're still better off
using middleware. This way you can place any files with sensitive data
(password
Mike - thanks for your help here. You're absolutely right about the
need for some kind of middleware and although I've never setup nor used
Livecode Server I find the idea kind of intriguing. For now I've asked
my son who I work with daily to write the middleware piece using PHP.
This should
to:use-livecode-boun...@lists.runrev.com] On Behalf
Of Ray
Sent: Tuesday, April 05, 2016 10:51 PM
To: use-livecode@lists.runrev.com
Subject: Re: Error: Unable to open the database file
Mike - if I set the folder to the area I've set up to work with this,
"http://54.210.118.224/Downloads/&
Subject: Re: Error: Unable to open the database file
Mike - if I set the folder to the area I've set up to work with this,
"http://54.210.118.224/Downloads/";, I get "can't open that directory"
returned in the result. I can read files at that location but I get an
&qu
Mike Bonner wrote:
> You can write your own middleware using LC server if you have it set
> up on your remote.
Does anyone here know of a good tutorial on using LC Server as DB
middleware?
This comes up a lot, and it would be great to have a URL to pass around.
Related: anyone here using An
You can write your own middleware using LC server if you have it set up on
your remote. I'm afraid I don't know enough about sqlite concurrency
issues and how to handle them, but since the server that has your sqlite is
an http server (I think most of us had been thinking it was a local network
sh
I thought of downloading it, updating it, and then putting it back on
the server but that wouldn't work if two users simultaneously did so.
Since I'll have many users using the database simultaneously everything
has to be done on the server. I know only one user can write to an
sqLite databas
Ah. Do you need to update the file in place, or just be able to use it with
your app? If the second, you might put url "
http://54.210.118.224/Downloads/yourfile.sqlite"; into URL
(specialfolderpath("tmp") & "/yourfile.sqlite")
at which point you can use revopendatabase to open the local copy of
Mike - if I set the folder to the area I've set up to work with this,
"http://54.210.118.224/Downloads/";, I get "can't open that directory"
returned in the result. I can read files at that location but I get an
"error 405 method not allowed" if I try to write files to that
location. Could th
Mike - if I set the folder to "http://54.210.118.224/Downloads/"; I get
"can't open that directory" returned in the result. I can read files at
that location but I get an "error 405 method not allowed" if I try to
write files to that location. Could that be the problem?
Regarding mapping the
can you map the server to a drive letter? (or mount it to a folder on the
local system) If so, that might help.
Alternatively, can you "set the folder.." to a path on the server and see
"the files"? If you can successfully set the default folder, then you can
just supply the filename and see if
I did read some about the file locking issues so I'll continue to look
into that.
Regarding testing with sqLite3, I'm not sure what to do with it. I
downloaded the pre-compiled binary for Windows 64. It gave me 2 files,
sqlite3.def and sqlite3.dll but I'm not sure what to do with them.
She
I suppose I should also mention the usual caveat about using sqlite over a
networked file system, which is that sqlite relies on file system locking
to preserve data integrity and some networked file systems are buggy in
that area according to the sqlite website.
On Tue, Apr 5, 2016, 3:57 PM Ray
Peter - thanks for jumping in here. Yes, I can read and write files to
this location and, as a matter of fact, I can even do a straight read of
the database file on the server and get the same cryptic characters back
I get when I read the local copy. I just can't establish a connection
to it
You might want to try opening the database with something other than
Livecode in hope that you will get a more informative error message.
sqlite3 is the official sqlite command line tool. It's distributed with
OSX but not sure if it's included with Windows.
Are you able to access any other files
Devin - thanks for the idea but that's not it. I just checked and
everything on my Windows 8.1 system matches case with the database file
path on the Linux server. I even tried changing the name of the
database file to all lower case but that didn't work either. Thanks...
On 4/5/2016 3:38 PM
Ray,
You may have moved your DB file from a system that is not case sensitive, like
MacOS, to one this is case sensitive, like Linux. Do all of your folders and
file names have the same exact spelling, including upper and lower case
letters, as the string in your path variable?
Devin
> On Ap
...one other note. I'm guessing calls to sqLite need drivers. These
drivers are probably built in to Livecode and the OnRev server which
would explain why LC's database commands works so well locally and with
the OnRev based samples.
If this is the problem, does anybody know how I could insta
48 matches
Mail list logo
