Re: Shell Scripting SQLite
Re: Shell Scripting SQLite
- Subject: Re: Shell Scripting SQLite
- From: Bruce Robertson <email@hidden>
- Date: Fri, 30 May 2008 18:26:49 -0700
> Hi Bruce,
>
>> But I still don't have what I want, which is to hold the database
>> itself in a variable.
>>
>> The above technique works with a "dump" verion of a database. A set
>> of SQL instructions.
>>
>> Send all the instructions to sqlite and make it regenerate the
>> entire database and then query it when done. But why do I have to
>> bother with all that regeneration?
>
> I think this is the bottom line for you:
>
> You could conceivably dump an entire SQLite database file into an
> AppleScript variable that you could then store in a FileMaker field.
> But you will have to write it back to disk whenever you want to access
> it.
Well, we've already proven that's not true. Though maybe it depends on what
you mean by dump. Maybe you merely meant "read native sqlite file".
If the sqlite database is in dump format I can send it to sqlite to work on
directly with no file involved, using a memory database.
The only problem is that it does not appear that you can capture the results
if you have made any changes to the memory db.
Regarding mulitple databases, the starting point is that I'm a FileMaker
developer. The data will always start there.
I don't see where Database Events comes into the picture at all.
> Something simple like:
>
> set databasePath to "/Users/bruce/Documents/myDB.sqlite"
> set databaseContents to do shell script "cat " & quoted form of
> databasePath
> tell application "FileMaker Pro"
> -- set the contents of the field you want to databaseContents
> end tell
>
> But in order to later use that database, you'll have to write that
> same data back to a file, such as just a temporary file, so you can
> get SQLite to access it.
>
> This is a very convoluted way to do it. Of course FileMaker itself is
> storing the data ultimately on disk, though you may seem to be
> accessing it through memory.
>
> If we take the suggestions as far as I've seen so far, you would have
> the bizarre situation of three database engines:
>
> 1. Data stored in SQLite.
>
> 2. FileMaker storing the SQLite database.
>
> 3. Database Events (a database engine) shifting the SQLite data in and
> out of FileMaker.
>
> So, I suggest stepping back and reconsidering the method. Perhaps you
> can do all that you need in SQLite directly, without storing in
> FileMaker. It's likely to me much faster, simpler and open to linking
> with other systems. You can fairly easily coordinate both database
> systems and funnel output from one into the other, without trying to
> totally embed one in the other.
>
> HTH
> Tom
> BareFeet
>
> --
> Comparison of SQLite database tools for Mac OS X:
> http://www.tandb.com.au/sqlite/compare/?ml
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden