after much searching I am going to pose my question here. If there is a duplicate and my search-foo abilities failed me I will gladly defer to it. On to the question.
I have a heavy background in service and web applications, with centralized database servers in an 'always on' way. However, a friend of mine is in need of a simple CRUD application (probably C# due to my limited experience with other GUI libraries/APIs) to replace a costly solution he currently has.
The application itself is very simple and I have planned to use Dropbox as a network layer to keep it even simpler. The issue I'm having trouble solving is that I need a good way to handle a portable database for authentication/authorization. I was considering SQL Lite stored in a read only folder within Dropbox so that it stays current while connected to the internet but doesn't require a network connection to function (They will not always have internet when using the program).
I am looking for suggestions, reading material, or experience with a similar design as a starting place.
Thanks for taking the time to help.
I recommend Sqlite. Works on almost all platforms and pretty easy to use. With .NET I use a micro ORM with it like Dapper.
Here is an example: http://blog.maskalik.com/asp-net/sqlite-simple-database-with-dapper
You can also use SQL Server Compact Edition (SQLCE) to achieve this very quickly. VS provides designers for making SQLCE database files, and ADO.NET plays nicely with it as well. It also supports simple replication as well.
Related
Many thanks #Mirko for the reply and comment. So sorry if im not clear myself.
I'll try to make it alot more understandable.
First thing is, I want to create an application for a Data Entry Form on Windows (Windows Form Application .exe). This application required database
and for a database server im thinking about SQL (Need some advise here on the server).
After the Form-Design completed and linked to the database, i want it to be able accessing PDF/PNG and stamping also, For approval purpose. Thus i need some file transfer server for this and some new coding line for this function. (I need a lot of help here especially the coding line).
Please note i've also tried making a form-based application on VBA Excel and use it's sheets for the database. But im struggling on how to make an access for File transfering and stamping (Approval) protocol. Thus lead me to C# on Visual Studio, hoping this coding program could handle such file-embed system.
Edit: Nico, I am not sure this will make a great SO question. Sorry, I cannot provide this detailed feedback in comments as they do not allow enough text. You are asking for advice that is in my opinion too broad. Meaning you really have many considerations here and are in essence asking (I think) how do I build a document management and approval (workflow) application.
You may want to look into document management solutions (I am no expert on those), but many handle approval flows and meta-data on documents well.
I would recommend you carefully consider even your starting assumptions. In my opinion if you are building a green-field application now you should decide between WPF (instead of Windows Forms) and a Web Application (that is in the .NET space) and I would probably recommend ASP.NET Core Razor Pages. If more than one person will use this application I would lean towards the latter strongly as it is more easily accessed and updated.
I am not the best person to answer how to do the Stamping approval part, but you may want to consider either an existing document management solution (maybe DocuSign, etc. as an integration) as they may offer you the features you are looking for out of the box. If not take a look at PDF libraries in the .NET space (I personally used Aspose in the past, but they tend to be expensive).
If you are looking to track metadata about the documents to be uploaded/approved SQL server is often a good choice, but since you are quite literally seeming to aim for document management, more document-centric options maybe a good fit (MongoDB, Cosmos (Azure), DocumentDB (AWS), ...) as they allow you to store arbitrary meta-data.
I'm about to release a small tool which uses a database connection for storing data. The question is: How can I prevent people reverse engineering my code and getting the Username and Password to gain access to the database?
For earlier projects (which were used only by myself), I defined the connection-string just as a global variable inside my app. But that's highly unsafe as it only takes minutes to get this string out of the exe.
Also a lot of methods to obfuscate code can be reversed.
I am really a big fan of providing code but I don't know what to post. This is more a question about the theory. Coding is the part I'll take care of myself.
Here is a small idea from me which I don't really like that much:
I could place a second tool on the server. The real app would connect to this second tool, give over the data and the second data would finally connect to my database itself. This way the connection-string would be stored inside the second app where nobody can grab it.
The fact of the matter is that storing sensitive information on the client machine is highly vulnerable to attacks against your database. A suggestion you can look into is a Three-tier architecture model for your application (http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture). In a Three-tier architecture, you have your presentation layer (your application), your logic tier (this layer will be the central pit stop for all your clients will have access to your database), and you have your database layer (the server where your database is). With this architecture, you can ensure all the data being stored and being retrieved from is from a singular source and high level security.
In the past (and still in the present), programmers would have to create their own socket servers or do advance network programming to develop a solution like this, however Microsoft has developed a tool called Windows Communication Foundation (WCF) which takes away the pain of coding your own socket server and lets you focus on developing your own implementation. Be warned though, WCF is secure by default, but it is no excuse not to research into ways of making your product robust against hackers (like knowing what protocol you are going to use, what security measures you are going to use (Transport vs Message, etc), encrypting data on client side so potential viruses don't uncover sensitive informations, etc). In saying that, WCF is a highly polished service and is really easy to get something up and running.
A good beginner video tutorial on WCF can be found here: https://www.youtube.com/playlist?list=PLhq7kqloVlM-bI9W_7iDZhObAeyrFt1y_
EDIT: The playlist for the videos are gone, but the videos themselves are still there. Just search through all his videos looking for the keyword 'WCF'
Here's the link: https://www.youtube.com/user/JesseDietrichson/featured
I will soon begin the painful*(kidding)* process of migrating multiple, separate, Access Applications to "Real" applications*(notice the quotes, no flame wars please)*. Most likely this will be Web Apps as the usual reason is multiple users and deployability but I will take it case by case.
Some of these are traditional Access apps using Access as the back end and others are using SQL Server(a central one) as the back end.
What I am looking for is a combination of your experience doing this and what resources you used to help.
Websites, apps, standards, best practices, gotcha's, don't forget's, etcetera.
I am a 1 person C# shop with SQL Server back end so whether Web or not I will be looking that direction.
Also, is it overkill or unattainable to try and develop a Framework for this kind of thing? Would there just be TOO MANY variables to even try and walk this path? Anyone ever try this?
Some further info based on below questions. We currently have ~250 users and they are spread between 5 Locations.
What I meant by deployability is perhaps a little vague. I simply meant that we are a Non-Profit Organization and as such we do not have the best bandwidth available so deploying full apps, even through ClickOnce can be tricky when combinded with the highly fickle nature of my users*(I want that box purple, no green, no get rid of it altogether type stuff...)*.
My idea is to try and develop a "framework", of sorts, that will help to streamline the process of moving an Access App to a .Net App.
Now I fully understand that this "framework" may be nothing more than a set of steps and guidelines; like, Use ORM*(LINQ2SQL or SubSonic)*to generate DAL, Copy UI to corresponding UserControls, rewrite Business Logic.
I am just looking for your experience/expertise to help me streamline my streamlining process... ;)
Those apps which use an Access database to store tables and which need web access should first be upsized to SQL Server. There is a tool from the SQL Server group. SQL Server Migration Assistant for Access (SSMA Access)
Then consider moving to the web only that portion of the app that requires remote access. And leaving the rest of the app in Access. That could save a considerable amount of time.
Alternatively consider going to Terminal Server. That along with a VPN means just some software licensing costs and next to no work on your part.
That said what do you mean by "multiple users" and "deployability"? Possibly we can give you some suggestions there. Access is multi user out of the box. However if you have mission critical data or can't rekey the data in the event of a corruption or have more than 25-50 users on the LAN then you should be moving the data to SQL Server.
Now that it's public Access 2010 can deploy applications to the web. All kinds of very interesting stuff can be done. For more information check the Microsoft Access product group blog or my blog with the appropriate Access 2010 tags
Speaking from experience I think you would need to upgrade on a case by case basis. Upgrading is essentially a re-write from scratch and you should take the opportunity here to re-design as necessary. The type of application structure and code style used for Access (likely to be procedural I'm guessing) is very different to a well designed OO .Net app.
You will be able to re-use the SQL Server databases of course and, depending on the apps maybe even the Access ones. If you're feeling brave you could even try the upsizing wizard although I wouldn't recommend it as we found the results less than ideal.
I would also advise you take a look at some kind of ORM tool (we use Subsonic) as this can massively reduce the amount of boiler plate code you need to write. Some ORM tools will also generate DDL for your database too.
We follow these standards (good idea to pick a standard early on and stick to it we found) and also found this really useful to get up and running.
Hope this was some help.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am the lone .NET developer in an non-IT organization. I've been asked to develo ae .NET application using Microsoft Access as the back-end (existing DB).
I don't know where to start.
Since I'm developing by myself, what should I keep in mind to avoid during development? What situations does only a lone developer face?
Please include Microsoft Access specific advice in your answer, since that is germane to the question.
Where to start?
Choose a development environment (I would suggest Visual Studio 2008 Express or Professional, depending on the budget and the need for features of the Professional version)
Even for one single developer: choose a Version control system !!!! (Subversion has only little administrative overhead, fine for one developer)
Choose a .NET Framework version (3.5 is fine unless your application has to run on Win2K; for Win2K use .NET 2.0)
Choose a mature programming language (C# or VB.NET, what you or your boss likes best)
Choose a GUI technology (for a single developer, I would suggest using WinForms, unless you are going to write a Web application or a command line utility)
Choose a mature DB access technology (ADO.NET works for a lot of things, unless you have very high performance requirements that are better dealt with old ADO/OleDB or DAO)
EDIT: use Google to find some entry examples according to the choosen technology, or buy yourself a book. For example, here is one for C# using OLE DB to access a MS Access DB. This Access site is a good starting point, too.
EDIT2: make yourself familiar with "Microsoft Access" (the Office Application). Not because you are going to use it like a typical user, but you will probably need it for administrative purposes. And the VBA & SQL documentation included will be sometimes helpful, even if you code with C# or VB.NET
EDIT3: for reporting purposes, choose a reporting technology. There are plenty of possibilites here, depending on your needs, your skills and/or budget, for example
Plain ASCII or CSV reports (coded by hand)
HTML or XML reports
using Excel as reporting engine
using a PDF library like Report.NET
using a third party tool like Crystal Reports
You will find a lot of helpful links when you give "report generation .net" to Google, for example this one.
And finally: come back to SO and ask more concrete questions when you come to the point where you have them.
There might be other constraints, depending on what code is already existing in your organization. And I would avoid technologies like F#, WPF or Linq to Entities.
Your question is too vague to give more than just general advice. If you have already developed other .Net applications, then the approach to developing this new application should not really be any different.
Database considerations:
The only things to bear in mind when using MS Access as a back-end database are:
Scalability - MS Access does not
scale very well and is only suitable
for a small number of users
*EDIT: Numbers vary depending on the type of activity the users are performing - for a reporting solution, Microsoft themselves suggest that up to ~100 concurrent users is the maximum - this white paper provides more information *
Security - MS Access does not offer the same sophisticated levels
of security that you will find in
other database products (SQL Server,
Oracle, MySQL)
SQL Syntax - there are some subtle differences in the way you
write certain types of query for MS
Access
Other Limitations - MS Access does not support stored procedures, so all your data access code will have to use inline SQL Commands (command.Type = CommandType.Text)
The maximum database size supported by Microsoft Access is 2GB - keep an eye on the growth of the database
Design considerations:
Does the existing MS Access database already have some user forms and code modules in it? If so, you could use these as the basis for your application - MS Access uses Visual Basic for Applications (VBA) as it's programming language and there are no tools/utilities that I know of that will port VBA to VB.Net
Do similar applications exist elsewhere that could help inform your design?
Keep data access code out of your forms as much as possible - try to keep data access code in a separate class/DLL so that it is easier to maintain
EDIT: as others have suggested, try to avoid having instances of ADO.Net connection and command objects scattered throughout the user interface - put all database connection code in one class/DLL so that it easier to fix/maintain/replace. I'd also suggest putting all your SQL query statements in a separate class or module for the same reason. *
Follow any in-house guidelines that you, or others before you, have put in place.
Keep maintainability in mind - someone after you may have to make changes. Use comments in code and give your objects (forms/variables/function names) sensible names
Take regular backups of your code - put a copy on a network drive or USB drive every day
One point of advice, encapsulate all Access-specific code within a single class. The class should at least be able to:
locate the Access .mdb file
create and open all OleDbConnection objects
It's critical that all Connections are guaranteed to close, so wrapping their use in a using block is a very good idea
(Possibly) build and execute all OleDbCommands (removing the db-specific logic from the consuming components--they should be able to make data-requests and retrieve results while transparently creating the Connection & Command, etc.
For accessing the Access database, you could maybe have a look at NHibernate? As far as I know it supports Microsoft Access and using a library like that could perhaps make things easier if you are going to move the data to some other kind of database later on.
If you are already familiar with a .NET language and MS Access then my advice would be to start off by developing a very simple MS Access database and write a small .NET console application that connects to that database and performs some basic functions e.g. querying/inserting/deleting/updating. Then its just a case of builiding on top of this piece by peice, introducing GUIs/separate libs (dlls) etc on the way.
Unfortunately for you .NET Linq to SQL (ORM) does not support MS Access databases so you will have to develop your Business Objects from scratch (not always a bad thing!).
Here is a good starting point MS Application with C#.
There is a lot of good advice here, all I would add is be sure to build all your data access and modifying classes behind a well defined interface(s). I am sure there will come a time when this application out grows MS Access and having well defined interfaces will make upgrading to another database easier.
So my company stores alot of data in a foxpro database and trying to get around the performance hit of touching it directly I was thinking of messaging anything that can be done asynchronously for a snappier user experience. I started looking at ActiveMQ but don't know how well C# will hook with it. Wanting to hear what all of you guys think.
edit : It is going to be a web application. Anything touching this foxpro is kinda slow (probably because the person who set it up 10 years ago messed it all to hell, some of the table files are incredibly large). We replicate the foxpro to sql nightly and most of our data reads are ok being a day old so we are focusing on the writes. plus the write affects a critical part of the user experience (purchasing), we store it in sql and then just message to have it put into foxpro when it can. I wish we could just get rid of the foxpro, unfortunately the company doesn't want to get rid of a very old piece of software they bought that depends on it.
ActiveMQ works well with C# using the Spring.NET integrations and NMS. A post with some links to get you started in that direction is here. Also consider using MSMQ (The System.Messaging namespace) or a .NET based asynchronous messaging solution, with some options here.
MSMQ (Microsoft Message Queueing) may be a great choice. It is part of the OS and present as an optional component (can be installed via Add/Remove Programs / Windows Components), meaning it's free (as long you already paid for Windows, of course). MSMQ provides Win32/COM and System.Messaging APIs. More modern Windows Communication Foundation (aka Indigo) queued channels also use MSMQ.
Note that MSMQ is not supported on Home SKUs of Windows (XP Home and Vista Home)
Its worth mentioning that the ActiveMQ open source project defines a C# API for messaging called NMS which allows you to develop against a single C# / .Net API that can then use various messaging back ends such as
ActiveMQ
MSMQ
TibCo's EMS
any STOMP provider
any JMS provider via StompConnect
You may want to look at MSMQ. It can be used by .NET and VFP, but you'll need to rewrite to use them. Here's an article that tells you how to use MSMQ from VFP. https://learn.microsoft.com/en-us/previous-versions/visualstudio/foxpro/ms917361(v=msdn.10)
Sorry if this isn't what you are asking for...
Have you considered some sort of cache behind the scenes that acts a bit like the "bucket system" when using asynchronous sockets in c/c++ using winsock? Basicly, it works by accepting requests, and sends an immediate response back to the web app, and when it finally gets around to finding your record, it updates it on the app via AJAX or any other technology of your choice. Since I'm not a C# programmer I can't provide any specific example. Hope this helps!
Does the Fox app use .CDX indexes? If so, you might be able to improve performance by adding indexes without needing to change any program code. If it uses .IDX indexes, though, the change would have to be done in the actual app.
As the problem is with writes, I would look more towards >removing< any unneeded indexes on the tables. As is common in RDBMS, every index on a FoxPro table slows down a write operation as the indexes need to be updated, and as you aren't reading directly from (or presumably directly querying) the table you shouldn't need very many indexes. You might also want to look at any triggers or field rules on the tables as they may be slowing down the write operation. Be sure your referential integrity is still preserved, though..