Hello.

Are you planning to create any articles about Stores? I'm struggling to see how they are any better than just sticking the file in a blob field?

I suspect they might be useful for a current project, but there doesn't seem to be much information about it. I've tried following the "Replication"
article but struggled to follow it. The Stores information I'm looking for doesn't seem to be there, mainly because the article is about another
subject.

For instance, some of the questions I have are:

1) Can sub folders beneath the designated folder be included within the Store? This would be really useful for me!

2) What happens if you try to save two files with the same name into the store?

3) When mapping to a local folder, what happens if User A adds a file into their local folder. Does this automatically appear in User Bs local folder?
Also, what happens it User B deletes the file from their local folder? Has User A lost it as well?


Are there plans to create examples to show how you image Stores can be used?

Many thanks
IanH.

As a follow up, I've spent a bit of time playing with Stores using the DB Manager but seem to be finding more questions...

Within the DBManager I've created a local store.

Within my OS I've copied a text file into the specified folder. But this file doesn't initially appear within the main window of the
manager. I have to select the tree on the left before it appears - Is this a bug in the manager?

I then modified the store privileges to the following:

Administrator:
Select = True
Create = True
Alter = False
Drop = False

Administrator2:
Select = True
Create = True
Alter = False
Drop = False

Public:
Select = True
Create = False
Alter = False
Drop = False

System:
Select = True
Create = True
Alter = False
Drop = False

By doing this, I thought the file would be protected. But I tried deleting the file from my local folder, and it disappeared from my local
folder and the store? If any old user is able to do this from the OS, there doesn't seem much point in protecting the file on the database
side?

I have also managed to get the Manager and the local folder out of sync. I deleted a file in the store from my local folder, using the
OS, but according to the Manager, it remained within the Store.

IanH.

Ian,

Probably you are already aware of it, anyway you can find information
about stores in the manuals here:
http://www.elevatesoft.com/manual?action=mantopic&id=edb2&product=b&version=2006&category=4&topic=26

and here:
http://www.elevatesoft.com/manual?action=mantopic&id=edb2sql&category=0&topic=20


> 1) Can sub folders beneath the designated folder be included within the Store?
No. You can however create other stores to point to the sub-folders.

> 2) What happens if you try to save two files with the same name into the store?
The second file will simply overwrite the first one.


> 3) When mapping to a local folder, what happens if User A adds a file into their local folder.
> Does this automatically appear in User Bs local folder?
> Also, what happens it User B deletes the file from their local folder? Has User A lost it as well?
Local Stores are only "pointers" to OS directories, so if 2 stores
"point" to the same directory - yes, they will always see the same
files. However I'm not sure what do you mean with "local folder"...

--
Fernando Dias
[Team Elevate]

Ian,

> Within my OS I've copied a text file into the specified folder.
> But this file doesn't initially appear within the main window of the
You must refresh (F5) the explorer to see the changes.

> By doing this, I thought the file would be protected. But I tried deleting the file from my local folder, and it disappeared from my local
> folder and the store? If any old user is able to do this from the OS, there doesn't seem much point in protecting the file on the database
> side?
When you use Client/Server and Remote Stores, clients simply don't have
access to server folders, so everything is controlled by EDB server and
you can set a very effective security scheme for stores, if you want.

If you use file sharing mode users can access files directly throw the
OS, so as you already know, there is no way to prevent users from doing
whatever they want to do with files - but that's how local stores are
designed - it's a perfectly normal way to add/remove files from a local
store. It's not less nor more secure than the database itself - nothing
can prevent users from deleting the database files if they want.

> I have also managed to get the Manager and the local folder out of sync.
I couldn't reproduce this. Maybe you didn't "refresh" after deleting
files...

--
Fernando Dias
[Team Elevate]

Hi Fernando

Thanks for the response.

I'd read the 2 pages in the manuals, and whilst they do describe how to use the stores function, but they don't provide any context as to why
you would ever want them? Like I said, I'm struggling to see how they are any better than using a blob field and storing the file there. If they
are intended to be used as a common file repository, then why hasn't folders been included? It seems like an obvious omission.

I think I'm completely missing the point with stores - but I can't find any guidance as to what the point of them is?

I'm currently working on a database that is a file repository for Users. Uses can check files in and out of the database to their local machine.
This also includes the folders the files are stored within. Think of it as a basic source code repository database (although it's not for source
code!) Should I even be considering stores for something like this?

I don't think using multiple stores, one per folder, would work very well. I would end up with hundreds, many with the same name - a
maintenance nightmare.

Are stores just a by product of implementing Replication? If so, I can understand them better and why there are apparent limitations.


Re: F5 on the Manager.

Yep I tried this, in fact it was how I expected it to work. The only way to get the file to appear was to close the store and reopen it within the
manager.

> I have also managed to get the Manager and the local folder out of sync. I couldn't reproduce this. Maybe you didn't "refresh" after deleting
files...

Perhaps - it is possible.

Thanks

Ian

Ian


Here's my (non-stores user) take on it. Stores were written as part of the replication capability in ElevateDB (so you're right in your comment). People being people will find other uses for them. They are best used in a client/server environment since then the built in transport layer can be used to move their contents around.

They are not intended as a high volume database component (now sit back and watch someone come up with a brilliant high volume use eg the replication app David Cornelius is building is checking every hour = low volume. Also they are not intended as a replacement for a blob field.

Roy Lambert

Hi Roy

Many thanks - this makes a lot more sense now!

IanH.

Ian,

Roy already answered your question, I'd like only to add one note:

One of the possible uses for stores is the automation of database
backups using SQL Jobs: Tasks like deleting the old backup files, move
backup files from one disk to another, possibly from a local disk to
another computer or to an external disk, etc. can now be done using only
SQL, and this is a very interesting feature, and also an example where
blob columns couldn't help.

--
Fernando Dias
[Team Elevate]

> Here's my (non-stores user) take on it. Stores were written as part
> of the replication capability in ElevateDB (so you're right in your
> comment). People being people will find other uses for them. They are
> best used in a client/server environment since then the built in
> transport layer can be used to move their contents around.

Yes, people WILL find many uses for stores.  I think it's an awesome
concept and my mind is just buzzing with ideas, but I can't implement
them yet because I'm busy with other stuff.  But it is a major
component, indeed the transport backbone, of replication.  It's very
nice that it "just happens" to be flexible enough to work for other
uses as well.  

> They are not intended as a high volume database component (now sit
> back and watch someone come up with a brilliant high volume use
> eg the replication app David Cornelius is building is checking every
> hour = low volume. Also they are not intended as a replacement for a
> blob field.

I'm using both blob fields and stores and each has their purpose.  It's
very easy to put a file in a store, either programmatically through EDB
or manually using Windows Explorer.  Using BLOB fields requires code,
or at least EDB Manager.

One idea I have for using stores that has nothing to do with
replication (at least on the database level), is something akin to
Windows FolderShare.  Have you heard of it?  Well you create a free
online account (foldershare.com), create a virtual folder, and point it
at a folder on your hard disk.  Then you go to a different computer,
login to your foldershare account, and point the virtual folder at a
folder on that computer.  Then just wait.  The files get automatically
copied over in the background.  It's really cool to be able to create
files on one computer, then go to another computer and see them there
already!

This idea could easily be implemented with EDB Stores.  You just drop a
file into a folder that EDB is watching on a periodic basis and have it
automatically copy files from one folder to another.

This will be a future feature of the application I'm building for my
client that has 5 staff members in 3 disparate U.S. offices (Arizona,
Pennsylvania, and Oregon).  If there are spreadsheets, images, Word
documents, or whatever, they'll be able to share them with other staff
members by dropping them into a special folder.  Of course they could
be emailed as well, but some people don't like to clog up email folders
with large attachments.  Also, there could be stores created for each
of their customers and this would be a nice way of associating
customer-related files with those specific customers.  A "view" of
these folders could be added to their application with Windows
shell-extensions to automatically launch them.

Sure, there's some overlap of functionality with the database, Windows
OS, and internet protocols, but it's another option for use in EDB
programs that I find very nice to have built-in.


--
David Cornelius
CorneliusConcepts.com

Ian,

<< I think I'm completely missing the point with stores - but I can't find
any guidance as to what the point of them is? >>

They provide EDB with a way of allowing for direct file manipulation that is
both accessible via SQL (necessary for scripts, functions, stored
procedures, and jobs) and can be locked down via EDB security mechanisms.
They also allow for copying files from any ElevateDB installation to any
other ElevateDB installation, include local-local, local-remote,
remote-local, and remote-remote with a simple COPY FILE SQL statement.  If
you consider the fact that a remote store can point to another remote store,
the possibilities are fairly open-ended.  Think of the stores as a blend
between FTP and a database engine.  Enabling such access via FTP or some
other mechanism like resource sharing is very difficult to get accomplish
today in larger organizations, and this allows you to bypass those
mechanisms to allow for file transfers without much work at all.  Take, for
example, distributing a backup file from a remote office to the main office
in an automated fashion.  With the EDB stores, this can be done with a very
simple nightly job at the remote office and a local and remote store
definition for the remote office EDB configuration.

--
Tim Young
Elevate Software
www.elevatesoft.com