1

I'm working on a Windows application that is used for tracking document review and audit information for my company. The back end is a SQL server database and most of the user tasks are basic CRUD operations on the data that resides in SQL server. Most of the controls (listboxes, comboboxes, grids, etc.) are populated using simple SELECT statements from SQL Server. It's used entirely in-house and I have complete control over the application and the SQL Server. The end users only have access to the SQL data through the application.

What is the best practice for storing these control sources? Do the belong in the control's recordsource property when I design the form? (that's the simplest) Should I store them in a table in SQL server and load them into the controls when the form is loaded? (That's the most flexible because I can change the string with out redeploying the application) Is there something else?

  • I've seen it done both ways. You'll have to decide if the flexibility is worth the additional complexity and the performance hit you will take on the first trip to the SQL Server. – Robert Harvey Mar 19 '18 at 17:11
  • [...] most of the user tasks are basic CRUD operations on the data. This is rarely true. This is true for poorly deisgned, form-based applications. Users never think in term of CRUD. – sturcotte06 Mar 19 '18 at 17:39
  • Also, if you store document-based information, you should look for document store databases (i.e MongoDB). – sturcotte06 Mar 19 '18 at 17:44
  • I'm sure it's poorly designed :). I was using CRUD as a short cut for saying that they enter a new record when they begin a review, update notes and statuses as the reviews are conducted (listing findings, client contacts, etc.) and write reports looking for trends and patterns. The documents reviewed aren't stored in this database, they exist in a range of places--contracts as PDF files on the network, invoices in an EDI database, emails in a separate data warehouse, etc. – DataWriter Mar 19 '18 at 17:58
  • The document's data doesn't need to be in the database; you'll still store data for which the primary key is the ID of a document. This can be saved to a document database. – sturcotte06 Mar 19 '18 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.