Images (jpgs) and Replication

Hi,
At the moment we have apx 15 images per item (apx 5000/client).
Currently, these are sent to us from the client to our lan so they can be
QC'd.
They go through the QC process and a database pointer is allocated to the
database item (in tblItemImages ( itemID INT, ImageFileName varchar(255),
ImageFolderID INT )
tblItemImages is uploaded to the webserver on a scheduled basis (noon &
midnight) and the images are FTP sync'd at the same time.
We may have a requirement to upload the images every hour (or every few
minutes?), in which case the ftp sync becomes a large overhead.
My question is, how feasable is it to store images in SQL Server and have
them replicated to a remote server (dedicated 1kbps line).
The images are apx 25-50KB each and only 3 of the 15 images are needed on
the webserver.
Getting the images in and out of the database shouldn't be so much of an
issue.Rebecca,
it shouldn't be a problem. I've done that on a database with loads of
image columns running merge replication with >20 subscribers, some of
them connected by a standard ISDN connection. So in your case it should
work without too much problems. But then again in my experience
replication always creates some (un)expected problems.
Markus|||Moving from storing the images as files to storing them in image columns
would require modifications to the database model and website programming.
Why is the FTP sync becomming an overhead; does the FTP utility support a
feature for only transferring files that don't exist on the destination or
have an updated timestamp?
"Rebecca York" <rebecca.york {at} 2ndbyte.com> wrote in message
news:434e3f98$0$136$7b0f0fd3@.mistral.news.newnet.co.uk...
> Hi,
> At the moment we have apx 15 images per item (apx 5000/client).
> Currently, these are sent to us from the client to our lan so they can be
> QC'd.
> They go through the QC process and a database pointer is allocated to the
> database item (in tblItemImages ( itemID INT, ImageFileName varchar(255),
> ImageFolderID INT )
> tblItemImages is uploaded to the webserver on a scheduled basis (noon &
> midnight) and the images are FTP sync'd at the same time.
> We may have a requirement to upload the images every hour (or every few
> minutes?), in which case the ftp sync becomes a large overhead.
> --
> My question is, how feasable is it to store images in SQL Server and have
> them replicated to a remote server (dedicated 1kbps line).
> The images are apx 25-50KB each and only 3 of the 15 images are needed on
> the webserver.
>
> Getting the images in and out of the database shouldn't be so much of an
> issue.
>
>|||Yes it does, but the number of images is enormous and it takes ages just to
bring down the image file names and timestamps to work out which ones need
to be uploaded.
images*items*clients
3*5000*5 = 75000
Altho we do it per client at the moment, so it's only 15000 at a time, but
it's still alot of data to bring down.
"JT" <someone@.microsoft.com> wrote in message
news:uu39a8%23zFHA.3812@.TK2MSFTNGP09.phx.gbl...
> Moving from storing the images as files to storing them in image columns
> would require modifications to the database model and website programming.
> Why is the FTP sync becomming an overhead; does the FTP utility support a
> feature for only transferring files that don't exist on the destination or
> have an updated timestamp?