You COULD store the document in a binary type datafield in the process but this is NOT recommended due to the large impact this is likely to have on the size of your K2.net databases over time. I would recommend that you store the document in an external document repository (SPS or WSS are good candidates) and just store a link to the document in the process instance.

---

You could also try saving your documents as blobs in the SQL database. You will need to store instance details long with the blob to refer back to the process instance. To save space you could first compress and later reverse the process when needed. I am sure there are plenty of articles on the web on this subject.

SharePoint is okay but suffers from a document size limit and is an extra cost where it might not be needed.

At a push you could store within the K2 database and tag the field as "data on demand", however I agree with Neil as to the increasing size of the database.

If you are generating the documents yourself then you only need to store the variables needed to generate the document. Careful with this option as certain legal requirements in document management proscribe such regeneration.

Graham

---

I don't understand why there is a concern with putting attachment in the database other than the storage requirement. It's actually better to do it in side database because it supports transaction and more easily backed up and restored with the data itself.

Has anyone done putting the attachment in database and experienced performance issues?? That would be something I'd concern about.

SQL Server is scalable to terabytes.

---