I have a very rookie question regarding making a simple Access database but for some reason I'm having trouble finding the proper keywords to adequately Google the problem. I'm certain the solution is going to be a simple toggle or setting I need to flip somewhere but I'm not sure what I'm looking for.
I have a table, tblClients. Each row has name, address, etc. I manually inputted a bunch of entries in here from datasheet view. I created a split form, frmClients, which will be to update client info in a more user-friendly fashion. At the moment, when the user makes any modifications in the form view and hit save, it appears to succeed but the actual data in the table row hasn't been modified. Do I need to change a setting somewhere or is there a different mechanism to post changes other than Ctrl+S or the save icon?
If there is necessary additional information I neglected to provide, please let me know. Thanks for your help.
-Marissa
Related
I'm currently working on a notes app because I really dislike any notes app that I could find on the app store because the lists you can create are either:
only text
only checkboxes
lines of text followed by checkboxes or vice versa
But by now I found no app (except for Samsung's proprietary Samsung Notes app which only works on Samsung smartphones as it seems) that allows alternating use of lines text and checkboxes.
When thinking about how to implement this properly I had some issues coming up with a proper way of identifying when there is a checkbox and when there should be a line of text. For obvious reasons, just storing text and specifying an identifier like <chkbox> (or something along those lines) is not a good solution because checkboxes should only be placeable by clicking the respective icon. The user should neither be restricted to use the term <chkbox> (because for whatever reason he might want to use it) nor should injections like this be possible.
The best thing that came to my mind up until now was to store each line individually (identified by \n) in a list with dynamic datatype and for each line either store it as text object or string or as checkbox item. Finally, I could simply store the list as one single object in the database. However, I'm unsure whether that's good practice as I could imagine that it makes changes to the list quite cumbersome (e.g. for changing the ticked-value of one single checkbox we would need to store the entire datastructure again instead of just changing one boolean in the database)?
I'm working in Flutter and use Firebase Firestore as my backend/database. Although I'm mostly looking for a general approach/solution to this, with the chosen technologies in mind, is there any solution that would work better than what my recent thoughts are, or is there any serious flaws or drawbacks that I overlooked? Thanks in advance for any constructive input.
I should model a system that clients can apply some configuration on separated entities.
Let me explain with an example:
We have users that have a config tab in their dashboards.
We have a feature to send notifications on their browsers and we have a feature which we can send an email to them.
We also have a feature as a pop-up.
The user should be able to modify our default notification message, modify our default email template, modify our default text on email or elements.
For the pop-up, The user should be able to modify the width and height of the pop-up, change the default texts, modify background color, change the button location on the pop-up.
And when I want to send an email to the user I should apply these settings on the template then send the email. Also when the front-end wants to show those pop-ups, wants to get these configs from my API and apply them.
These settings will be more and more in the future. So I can not specify a settings table with some fields. I think it is not a good idea.
What can I do? How to design and model this scenario? What are the best practices?
Can I use a NoSQL like MongoDB instead of a relational database?
Thanks a lot.
PS:
I am using Django to develop this system.
I have built similar sub-systems before, by hand.
I don't know much about Django, but do some research to see if it has any "out of the box" or community developed / open source add-ons that do what you want.
If you have to do it yourself...
A key-value pair is not going to be enough, but it's close. You only need a simple data structure:
ID (how your code recognizes this property), e.g. UserPopupBackgroundColor.
Property name (what the user see's / how they recognize this property in the UI), e.g. "Popup Background Color".
Optional - Data type. This is essential if you want to do any sensible input validation. E.g. pop up height should probably expect an integer, and have a sensible min/max value on it, where as an email address is totally different.
Optional, some kind of flag to identify valid properties.
That last flag is bit of an edge case, but it's useful if you use the subsystem to hold more properties than you want users to have access to. E.g. imagine you want to get a list of all properties and display the list to the user - are there any 'special' ones you need to filter out that they should not see?
You then need somewhere to put the values, and link them to the user:
Row ID / GUID. You can use a unique constraint across the User and PropertyID if you wanted to instead, but personally I find a unique row ID is a reliable and flexible approach for most scenarios.
UserID.
PropertyID - refers to ID mentioned above.
PropertyValue
Depending on how serious you need to get, you can dump all the values into the one PropertyValue column (assuming you're persisting this in a database) - which means that column needs to be a string, or, you can add a column per data type.
If you want to add a column per data type, don't kill yourself. The most I have ever done is:
PropertyValue_text (text/varchar)
PropertyValue_int (or double)
PropertyValue_DateTime (date/time - surprise!!)
So when I say 'column per data type' I mean per data type your stack needs/wants to handle - not the 'optional' data types you define in the logic - since that data type is partially just about input validation.
Obviously if you use different logical data types, you can map those to data type columns in the database. The reasons for doing this (using the different data types in the database are:
To reduce the amount of casting you need to do (code to database, and vis-a-versa).
To leverage database level query features, which can be useful. E.g. find emails values and verify them; find expired date values; etc.
It takes a bit of work to build all this, but it's powerful once you get set-up because you can add any number of properties. If you are using the 'full' solution with explicit data types then adding new logical data types isn't too painful if you already have a few set-up.
Before you design and build this, think about future reuse, and anyway you can package it up for later - or community use. Remember it impact all layers (UI, logic and data).
Final tip - when coming up with the property ID's (that the code uses) make them human readable, and use some sort of naming convention so that adding new ones later is easy and follows a predictable path.
Update - Defining Property and PropertyValue in database tables is an obvious way to go. Depending on the situation you can also define Property in code - especially if you don't add new ones or change existing ones very frequently. Another bonus is that if you're in an MVP situation you can use the code effectively as a stub, and build out the database/persistence part for that later.
Im planning to use Leaflet Draw as part of a special wiki with an embedded map. Users should be able to draw geo-objects that are related to one or more pages in the wiki. As the wiki-pages the objects are saved in a database and can be modified by every user.
Problems:
How can i limit the number of editable objects to only one at a time?
How to keep the database consistent if two users are editing the same object at the same time?
How can i generte multi-objects/combine several objects (e.g. polygons) to a super-object (multi-polygon)?
Does anybody know some similiar approches to my idea?
Thanks.
You will have a single FeatureGroup for leaflet.draw's objects that can be edited. Simply figure out which objects will be edited and which won't be and add them to seperate FeatureGroups.
This can be handled in a few ways, maybe have a look around at general database consistency for this.
I'm not sure what you mean, maybe have a look at Well Known Text it might help you with storage here.
I was wondering if someone could point me in the right direction.
Here is my problem: I have a large form/checklist that I would like to make digital for ease of use.
Thoughts: I would like to use existing tools that would be easy to integrate. My first option is Access 2010.
My question: I would like to enter the questions into a database and then use those entries to auto generate a form that can be used to allow the user to input the actual data into the database. An example would be I have 11 Sections of questions and under each section I have sub-sections that can contain anywhere from 1-... how many every questions we need.
Is it possible to use data stored in an Access database to generate a form with Checkboxes that can be used to input data?
Please point me in the right direction. Obviously there is the option of just creating multiple forms or one big form, but I would like this form to easily be changed etc... Less work more automation.
Thanks,
Alex
Depending on the requirements of your project, this may be quite possible. If you want to use Access as both the back-end and front-end, then you'll need to work within a few limitations:
Because Access combines the user interface and design interface into the same screen, it requires a certain amount of trust that the user can't or won't try to get too creative with changing the data, seeing everyone else's data, changing the design of your form because they are bored, etc. There are ways around these problems, but they can get complicated.
Will all your users be using Window's machines with Access 2010 installed and with the original default settings? If so, good. If not, there may be ways that this could still work.
(There's more, but that's all I can think of right now)
To get started, here's a broad outline:
Make a table for your questions. This table would just have the questions.
Make a form using that question table as the source. Leave the checkboxes and other answer fields unbounded. Include a 'submit' button at the bottom.
The submit button will create a sql query to insert the user's answers into a 2nd table.
If you have any specific questions, we here at SO will be glad to answer them.
In order to dynamically and easily change the number of questions in the sections, what I would do is:
In the main Questions table, add a field called Section to allocate the questions into diffferent ones, and another one Yes/No field to select those that are included (you may also exclude them by leaving the section field empty, as you wish). This will solve the problem of changing the design easily. you probaly will need an admin form in order to do this changes, to avoid touching the tables directly, but this is your decision.
Secondly, in order to allow the users to efectively answer the generated form, you have to ask yourself if you want to accumulate the answer sets, and if you are going to control who answers
How are folks generally handling the whitelisting of foreign key values? Let's ignore the use case of an associated user record which brings an additional set of issues and stick to a fairly benign scenario: A Task belongs to a Project. When I create the task, I want to create it with its project_id value, but I don't want that value to be editable. The property is passed by a hidden field in the shared form.
I know I could just unset that property in the controller before calling save() in the edit action, but I was wondering whether anyone had a better solution. I've used/tried several, but all are laborious or less "universal" than I'd like.
Does anyone have a solution that they really like to solve this particular problem?
Thanks.
I handle this manually as well. The process is something like this.
Load object and show the edit screen to the user.
When user submits, take the primary ID and load the object again. Check ownership.
Have a whitelist of user editable fields, loop through those keys and populate your new object, leave everything else alone.
Save.
You could move this into some kind of before save hook or behavior I would say. But this seems the best practice with the RoR feature (we all know what happened in GitHub)