1

I wrote a support ticket system. Part of the ticket submission process allows the user to attach files. Once files are attached, the software creates a folder with the ticket ID number as the folder name, and stores the attachments there.

Each time the ticket is loaded, the contents of that folder are displayed in a listbox where they can be modified, added to or deleted, or opened.

The reason I did this was so that the attachment folders were easily accessible, even if the user was not using the software. This way they could send someone who doesnt have access to the software a link to the attachment folder.

The support ticket system is stored in an Access database, and runs out of a stand-alone Windows Form application.

Is this a bad practice? Will this lag the system out eventually? The software will be run off of a share drive, and the folders will be stored there as well.

I do not anticipate more than 60 users ever using this software.

I do not anticipate more than a few dozen requests per week, and requests could be archived once they were resolved.

user5480156
  • 47
  • 3
  • 8
  • 1
    you could just glue the Id to the attachment and store in one folder. e.g. `123455643_somename.jpg`. Might be easier to find rather than checking if a folder exists and then are they any files in it – Ňɏssa Pøngjǣrdenlarp Dec 15 '15 at 16:34
  • Interesting idea, I will check that out. – user5480156 Dec 15 '15 at 16:35
  • 1
    A caution I would give is that while you only anticipate a few dozen requests per week, you really need to clarify that assumption with business owners of the product. Make sure if you are going to base the architecture of the software on that assumption that it is outlined clearly and plainly in any and every spec, and make sure you communicate that clearly to people that it matters to. I say this because if at one point in the future a few dozen turns into a few hundred or thousand and the system cripples, you need something to go back to when the architecture needs an overhaul. – davidallyoung Dec 15 '15 at 16:59
  • 1
    Previous comment continued: Ensure that they anticipate the same amount of usage as well, as they may have a different outlook on future usage or have a totally different assumption about the scalability/availability of the application. – davidallyoung Dec 15 '15 at 17:01
  • 1
    Personally, I wouldn't create a directory for each attachment. I'd look for a way to store all attachments in one location where the names of the attachments are also stored in your Access database. Save the names of the attachments along with the other 'ticket info'. if you run into duplicate names make a loop that appends something to the end of the file name until you get to a unique name, then save the 'ticket' info – Rose Dec 15 '15 at 17:38
  • 1
    @Rose one of the issues is some tickets have multiple attachments, which means gluing the ID to the front of the name may work better. – user5480156 Dec 15 '15 at 17:56
  • 1
    @DavidY At what number of requests do you think this would become unsustainable? – user5480156 Dec 15 '15 at 17:57
  • Having multiple attachments will make it even more fun! if needed, create a separate table to store attachment file names that might exist. Link this table to the 'ticket' table by using any sort of ID field that fits in with what you are working on. – Rose Dec 15 '15 at 18:21
  • 2
    If you mean up to 60 simultaneous users, it might not be such a good idea to use an Access database. SQL Server Express is free and is better able to cope with many concurrent users. – Andrew Morton Dec 15 '15 at 19:15
  • 1
    @AndrewMorton How difficult would it be to transition to that down the road if that became the case? Would it just be a matter of changing the SQL string and connection commands? I assume SQL can do everything Access does, just with slightly different commands and required libraries/references. – user5480156 Dec 15 '15 at 19:18
  • 2
    @user5480156 It should not be at all painful if you have separated your database-related code from the rest of the code, which is regarded as a good practice - [What is the purpose of a Data Access Layer?](http://stackoverflow.com/q/59942/1115360). – Andrew Morton Dec 15 '15 at 19:27
  • 1
    RE moving to SQL Express, while you are right that it will do everything Access does, there are a few differences in syntax etc which may cause problems down the road. I'd advise making the change now rather than later. I can't think of a compelling reason to choose Access over SQL Server Express. – peterG Dec 16 '15 at 00:02

0 Answers0