I'm making a VB.NET application with an SQL Server 2005 in the background. Naturally the user can not edit the database directly but will use a number of UI features to be able to add and modify the data.
However, there are a few tables that should be easily accessible from the admin interface such as specific information about a vendor. What's the easiest way to let the user edit this data freely? One way would be to use a DataGridView but this could appear complicated to the user, plus I'm not sure exactly when to save the edited data back to the database.
The best way that I can think of is to create custom dialog boxes for adding, deleting and changing the information, but this seems like too much work for such a small feature.
You are either going to have to give them the data in a table format (like with the DataGridView) or you are going to need to build something that lets them edit individual records (like custom forms). It seems like a lot of work (and it can be) but there are some ways to cut down on the amount of work.
Check out how to use databinding in VB.NET. There's a tutorial here, another one here and many others out there. You can use databinding for both a table view or for individual records. Using a DataGridView isn't too complicated for a user as long as you build in the necessary support in code - make sure the row is saved if it has been changed and they move to another row (or prompt them), disable editing on columns that they shouldn't be able to change, validate the data before writing it back to the database, etc.
There are also code-generation tools like CodeSmith that can create a data access layer between the GUI and the database. Some of the templates you can get will even generate the actual forms for you.
The only other option I can think of is to give them direct access to the database through tools like SQL Server Management Studio and setting up logins that only have permission to specific tables/views but I would STRONGLY recommend against that.
Related
I'm one of several analyst and data engineers working within a Snowflake database. We all often have to write ad-hoc small bits of code to check tables and views. These are often quite repetitive tasks (e.g. filtering data based on a certain reference, joining FACTS and DIM tables to add context).
I'd like to create a Worksheet that we can all periodically add useful bits of code to. Just to save us time making joins or be a good starting place for writing longer bits of code.
I've previously used SQL Server where I was able to save template files with useful bits of code. I could open these files directly within SQL Server so it was really easy to open, edit and run these files. What are some similar features in Snowflake?
Thanks
Yes, but you must use the new web UI "snowsight". In the new UI you can share worksheets with team members and give them edit access. You can also import your worksheets from the classic UI as well.
Keep in mind that team editing doesn't work like google docs, where you can see each other typing. So be mindful of that. However, every version of the worksheet is automatically saved and available from the upper right of the interface.
https://docs.snowflake.com/en/user-guide/ui-snowsight-gs.html
https://docs.snowflake.com/en/user-guide/ui-snowsight-worksheets-gs.html
I have a task where I need to get inputs from user and perform some updates to the DB table. Now I knwo this is something needs to be done through a UI, but due to some limitations I have been assigned a task to do this through SSRS report. I know this is possible to do but is it a good practise to do updates or insert through a SSRS report?
First, SSRS is not designed for this kind of thing and, May be someone who has done this, I would advise you consider an Access Form against a SQL back-end, Sharepoint or an ASP.NET web form
I agree with Zaynul, this is not good practice. Interface wise, user expectation from reports is not that it causes updates or inserts, but retrieves data. Report automation tools (largely out of your control) like subscriptions could have this running in a way you don't want. It's probably being used as a substitute from writing an Interface element in a "program". Finally, lack of control of the parameter fields makes validating inputs more painful (compare with say, VB). If the drawbacks are unclear to you, you should probably avoid this path altogether.
If you need to do something like this bear in mind the drawbacks and take precautions
Confirmation parameters "Update? Y/N"
Preview what will be updated or inserted before allowing an update
Is there a way to "reverse" the update or insert
Is the change stored so there is an audit trail for changes done this way
Follow the same rules you'd use if you wrote a real interface/program for updates
My database is an Access Data Project, tied to a SQL Server 2005 backend. I'm trying to bind a form to a view that uses an INSTEAD OF trigger. Access thinks the view isn't updatable, so it's making the form read-only; apparently it doesn't take the trigger into account.
I suspect the problem is that SQL Server's metadata says the view isn't updateable. Querying INFORMATION_SCHEMA.VIEWS, for example, shows IS_UPDATABLE = NO. Despite that, I definitely can update the view by using UPDATE statements or using the SSMS GUI.
Is anyone aware of a method I can use to convince Access that this view really is updatable? I know there are other ways I could get read-write access to this form, but I was planning to use this view to limit certain users' access to a very specific subset of data, and it would make things a lot easier if I could encapsulate all of that data within this one view.
Access requires a PK on the linked table in order for it to be updateable - I think this is so the JET (or whatever the new one is) engine can uniquely identify the row to change.
This means you need to convert this view into an indexed view, which is a whole other can of potentially very complicated worms.
I would like to track changes on views data. I don't think it is possible out of the box with current sql server change tracking. Has anyone come up with a solution to this one?
//edit
I'm synchronizing data between two databases. Synchronization works mostly on views (some tables too), so I need to track changes that are being made on views data (insert/update/delete). The task is not trivial, because some views are just JOINS and others use PIVOT.
No. No, you cannot. I wish you could.
You can track changes with DDL Triggers.. Seems like these work on SQL Server version 2005 and above.
One benefit is for users that are just not going to use source control (It happens). This can be a problem if the use GUI view creating and don't want to export to the actual text.
This records the previous versions (you already have the current in the database itself) without any user involvement.
This would free you up from having to be the bottle neck and approve or apply every change.
I didn't read enough of this to see if it would capture the user who submitted the change.
Manage the changes in your source control server and generate your views WITH ENCRYPTION so people don't mess with them on the server.
Hopefully someone has been down this road before and can offer some sound advice as far as which direction I should take. I am currently involved in a project in which we will be utilizing a custom database to store data extracted from excel files based on pre-established templates (to maintain consistency). We currently have a process (written in C#.Net 2008) that can extract the necessary data from the spreadsheets and import it into our custom database. What I am primarily interested in is figuring out the best method for integrating that process with our portal. What I would like to do is let SharePoint keep track of the metadata about the spreadsheet itself and let the custom database keep track of the data contained within the spreadsheet. So, one thing I need is a way to link spreadsheets from SharePoint to the custom database and vice versa. As these spreadsheets will be updated periodically, I need tried and true way of ensuring that the data remains synchronized between SharePoint and the custom database. I am also interested in finding out how to use the data from the custom database to create reports within the SharePoint portal. Any and all information will be greatly appreciated.
I have actually written a similar system in SharePoint for a large Financial institution as well.
The way we approached it was to have an event receiver on the Document library. Whenever a file was uploaded or updated the event receiver was triggered and we parsed through the data using Aspose.Cells.
The key to matching data in the excel sheet with the data in the database was a small header in a hidden sheet that contained information about the reporting period and data type. You could also use the SharePoint Item's unique ID as a key or the file's full path. It all depends a bit on how the system will be used and your exact requirements.
I think this might be awkward. The Business Data Catalog (BDC) functionality will enable you to tightly integrate with your database, but simultaneously trying to remain perpetually in sync with a separate spreadsheet might be tricky. I guess you could do it by catching the update events for the document library that handles the spreadsheets themselves and subsequently pushing the right info into your database. If you're going to do that, though, it's not clear to me why you can't choose just one or the other:
Spreadsheets in a document library, or
BDC integration with your database
If you go with #1, then you still have the ability to search within the documents themselves and updating them is painless. If you go with #2, you don't have to worry about sync'ing with an actual sheet after the initial load, and you could (for example) create forms as needed to allow people to modify the data.
Also, depending on your use case, you might benefit from the MOSS server-side Excel services. I think the "right" decision here might require more information about how you and your team expect to interact with these sheets and this data after it's initially uploaded into your SharePoint world.
So... I'm going to assume that you are leveraging Excel because it is an easy way to define, build, and test the math required. Your spreadsheet has a set of input data elements, a bunch of math, and then there are some output elements. Have you considered using Excel Services? In this scenario you would avoid running a batch process to generate your output elements. Instead, you can call Excel services directly in SharePoint and run through your calculations. More information: available online.
You can also surface information in SharePoint directly from the spreadsheet. For example, if you have a graph in the spreadsheet, you can link to that graph and expose it. When the data changes, so does the graph.
There are also some High Performance Computing (HPC) Excel options coming out from Microsoft in the near future. If your spreadsheet is really, really big then the Excel Services route might not work. There is some information available online (search for HPC excel - I can't post the link).