I have a pretty simple .net 4 desktop application written in c# which needs to display some data inserted to a table on an SQL Server (2005). The data itself is quite simple, just one row of about 10 columns, (mostly counts of other data).
I could just poll the sql server from the application every x interval, but my preference is to have the sql server push the data out to this application if possible, as the timing of the "new data" is often irregular.
In short, I'd like to know if this is possible. Doing some research before posting this question, I found a few possibilities.
1) SignalR: I found this question which seemed promising, but this seems to be in the context of a web application rather than a desktop one. Upon review of the signalR wiki, it seemed to me that it requires some kind of web service or other http connection which I'd prefer to avoid.
2) Sql server change tracking, from this question. Firstly, I'm not on sql 2008 so I assume I'd have to install or configure it (which isn't a problem) but I'm also not sure if this will provide what I need.
I will mention as well that this client application could exist on 100+ different pcs which would all need to be notified on the data change.
So, is such a thing possible? I apologize if the question is a little vague - and thanks in advance for your help!
The SQLDependencyclass is supposed to cater to the very scenario that you are referring to.
While i do not have any personal experience using this, this article seems to be in line with your scenario
Related
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 5 years ago.
Improve this question
I'm working on a collaborative real-time drawing tool. My client is already written in C# and I need a server. I've done a lot of search on google, but I don't know how to choose a database and a language for the server side. I'm a beginner and I would like to have your help. In my database I need to store users information and their pictures, also users can chat together, so I'll be using sockets. Is it possible to build my server with nodeJs and a mongoDB database or C# and SQL. Also, what makes this difficult for me to choose is how can I store pictures (that users are working on) in my database and always sync with changes. Is that possible with Json (image represented by an array of bytes?) or there is another way for storing pictures and update them whenever a change is made by a user?
Thank you.
A lot of opinions will go into into my answer, but here goes...
Some assumptions -
Since your asking, your team size is approximately 1.
Since the team size is ~1, the customer base is smallish.
Since chat is not the primary function of the product, price, simplicity and time are important.
You know your way around the existing app, thus you are already familiar with C#, and also comfortable with nodeJS, SQL and mongoDB.
So ask yourself -
Firstly, what are you best at? What are you most familiar with? Do you have time constraints that can be best served with a more familiar stack?
What about storing your images in AWS S3 or similar cloud storage? Persisting binary data into an SQL database is not ideal, and it quickly causes issues with managing the size of your database backups.
What are the requirements for uptime/availability and scale?
Is there an off-the-shelf alternative chat program that you can plug in so that you have NO back-end? (i.e. freshdesk)
You database decision comes down to requirements. Lots of possibly irrelevant questions here i.e.
Does the user need to see their old chat?
How many users in a chat room?
How long do chat messages have to stick around for?
If no one is available on the other end, how will this work? How do you match users?
What reporting or administrative requirements are there?
Are there lots of object types with complex relationships between them that are best stored in an SQL DB?
Some recommendations -
Keep your database small - don't persist chat logs or purge them as soon as you can; Keep files over a few KB out of the db
If you choose .NET, consider WCF or signalR for communications
If you don't have to store chat logs, consider a memory database like redis with pub-sub capability
If you have to support and maintain the server, consider instead a Linux OS and compatible stack so your not woken up in the middle of the night when a Windows Update fails and the machine wont boot.
Consider virtualization. i.e. open up a free-ish AWS account and sniff around what technologies you could cobble together to do much of the work for you - a few lambda functions and you may not even need a server!
Personal favorites -
Linux
Redis for pub-sub and chat
object store (mongo/dynamo whatever) for user profile
S3 or comparable for images
The stack you choose is up to you but if you coded client in C# then it would be simplest to stay with that stack.
For me right now to do this task I would create a web api in ASP.NET Core 2.0. This will handle all the user info and image uploading as well as authentication.
I would use Entityframework Core which is an ORM that can map to any database you want (although support may vary). The new SQL Server Express runs on windows and linux so I would probably choose that. For the chat you can use SignalR.
Really it doesn't matter so much what you use as long as it can accomplish the job but if you are just starting out it make sense to pick a reasonably new stack (although not bleeding edge or you may have difficulty finding adequate documentation).
I think a good place to start is make sure you understand the following:
Difference between a 'database', 'database management system(DBMS)' and 'SQL'
SQL vs NoSQL DBMS. How is data stored and accessed for each?
mangoDB is a NOoQL DBMS. MySQL is a SQL DBMS.
JSON is a file format for representing data. Think of XML. It has nothing to do with arrays of bytes.
When you have clients collaborating on a picture, your server application will probably want to keep the picture in memory to allow for fast editing. You will want to save it to the database every once in a while. You can do that in many ways. You could also decide you want to store the files as bitmaps on the servers hard disk.
Most applications have a single instance of the server handling multiple clients so you want your server application to be written in a faster language. That being said with today technology and the scope of your application, pretty much any language will do.
A co-worker and I are working on some Pharmacy software (in C#) which deals with the management of patient profiles, patient drug prescriptions, etc. All of these different sets of data are stored in a sql server database (we're using 2008 standard but future versions are fine too). Each store has its own sql server instance on a local machine.
Our Goal:
We want to have "Store A" be able to access "Store B's" databases if need be. Basically in the event that perhaps a pharmacy customer is out of town and visits one of the other pharmacy branches.
Things I've thought of:
My initial thoughts were to basically keep an online server instance of sql server which could be accessed through a dns link (or perhaps IP). I was trying to figure out the best way to keep these in sync and I came across sql servers replication. Problem is I was going to use Transactional Replication with updating subscribers but since it's deprecated It's not really a long term option anymore. Microsoft suggests using p2p replication, but that requires enterprise edition and we're really trying to avoid that if we can. I wanted to use a transactional type of replication since it does a much better job of keeping records consistent (not having to wait for something like a merge agent job to run every hour or something like that).
Something I've thought about more recently is maybe having an internet based sql server instance, which would contain nothing but linked servers back to each stores local machine. I wouldn't have to worry about sync problems if other stores just worked directly off each others local machines. But I've read of a lot of people saying that this is a horrible security vulnerability so I'm not sure if this is even a plausible idea but I think maybe there's some way to make this work?
Anyways so this is the basic gist of what we're trying to do. I don't know if replication or linked servers would be the better route to take.
Edit:
What about bi-directional replication? I was reading a little bit about this but I'm a little unsure about if this is what I need or not. I don't want to have to stagger primary keys between servers or anything, since they are pretty important in identifying prescription numbers and stuff like that. But if I could do bi-directional replication, that could be good too.
Not really an answer but I have more space...
SQL Azure is a the 'cloud' version of SQL Server. A VPN is a way of creating your own private network over the internet. Do some research on these terms. Many applications are going cloud nowadays. You should really consider the likelihood that there will be no internet access.
With regards to replication, you can 'roll your own' replication if you own this application and you are happy to support it.
The basic premise is:
Create a trigger on every table which writes the PK of every change to a log table
Create a process which manages copying and merging only changed info (based on the log table) using subscribers and publishers
I'm trying to prepare to build a database driven .net application and I have hit a roadblock early on due to my lack of knowledge on this topic. Searching around didn't yield anything so here I am asking for help.
I'm receiving weekly data in xml format that will be added to a database and then reports generated using that data. I have a limited license on the xml files so only I can download them and I need to get the results to my end users as well. As far as I can see, I have 2 options:
Feed the data from the xml files into a web hosted database and then have each user connect to the database.
Upload the xml data to a server, have each user download it and keep a local copy of their own database. I'm thinking this will invalidate my license to the original data.
Things / questions of note:
The database holds weekly sports historical data for about the last 10 years.
I need to limit access to the database to only subscribed users.
I'll need to decide how the database will be built.
I need to decide what kind of hosting I'll need.
As you can see, quite an ambitious project for someone new to this. I haven't asked any specific questions so far:
What kind of hosting solutions shall I look for?
Should I use SQL? (Complete newbie on this subject)
Should I use clickonce and then host the application?
Do you have any book or tutorial recommendations that would cover a project like this?
Do I need a script to feed the xml into the database if I go that route? Will that script reside on the server and do it automatically even if I'm not there to instigate it?
I hope the general topic isn't too vague. I tried to actually ask specific questions on it and I'm aware I don't have any code to show as it's just in the early stages of thinking.
The question is a bit vague since you are early on in the decision-making process. However, I do believe that I can offer some help in directing your thinking as you proceed. I think in the situation you are describing, one key thing you should consider is to host your data via JSON/WCF/REST. If you look into these technologies, you will see that there are different ways you can offer your data based upon your developing requirements. For example, how are you going to do authentication? Are you going to allow third-party clients?
What you really don't want to do is allow direct database access, even for authenticated users. Instead, put something in front of it. If you are working in the .NET space, look into all of the different things WCF offers and pick one based upon what fits best. Once you pick that, then you will know what you need for hosting and deployment. Even if you are going to provide the clients as well as the server, this is still a good way to protect your data and provide a way to expand your offering in the future.
I am currently in the process of developing a program and not sure where to go from here...
I am using Visual C# and the DotSpatial frawework in order to do the GIS/GPS side of things but am unsure of what back end database to use.
I have had a look at PostgrSQL with PostGIS and also had a look at MSSQL as this now has Geospatial capabilities.
So what I am trying to achieve is the following with the software:
- The software needs to be used both at the persons desk, but also remotely while using the GIS/GPS side of the system to track the users travelling. (i.e. when locating where they need to go - this is custom data on remote sites). This is relatively easy to do with DotSpatial alone and not DB is needed.
- They have custom forms that capture data (text, lats/longs, photos) while out on site.
- The data needs to be able to sync up with the main database when they are back in the office
- This data needs to be viewable by everyone connected to the system once the system is updated
Ultimately if this can be a type of DMS then that would be great. So I am keeping that in mind as well.
Should I use a seperate DB for the datacapture side of things and something else for the main DB or should I use the same for both? Which one is easiest to configure? I would prefer when deploying the software that the installation goes smootly and dont have to manually configure each machine.
The main server is Windows 2008 Server btw.
Any help or suggestions would be greatly appreciated.
I use PostgreSQL with PostGIS on a daily basis. Although it is opensource it provides very good funcionality and performance.
Check this Cross Compare between SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6. This could give you a good idea
I second the recommendation for PostgreSQL/PostGIS. It works very well and is well supported by the community. I would note that OpenStreetMap uses PostGIS as well. Indeed, if you ever want to work with their data you'll be wanting PostgreSQL.
I will be building an in-house, Occasionally Connected App (OCA). What technologies would you suggest I employ.
Here are my parameters:
.NET Shop(3.5sp1)
C# for code behind (winform,wpf,silverlight)
SQL Server Backend (2005 or possibly 2008 pending approval)
Solo Developer
Solo SQL Administrator
Low Tech end users
Low bandwidth to 5 Branch offices
This is a LOB app but not a POS.
Majority of users have laptops that they take to Member's Home
The Data for this App is stored in 5 separate Databases, though in one SQL instance.
I am looking for specific recommendations on which path to choose. Merge Replication or Sync Framework database synchronization providers? SQL Express or SQL CE at the Subscriber? Can I use LINQ to SQL for the DAL?
Is a Silverlight 'Offline/Out of Browser App' Example Here, feasible?
This is my first LARGE business application so any experienced comments are welcome.
As requested here is some additional info on the type of Data. My users are Nurses and Social Workers who go to Member's homes and create "Plans" or "Health Assessment Reviews" for them. These are things like a Medication List or a List of there current "Providers". Steps to achieve members' goals or a list of there current/past Diagnosis's. Things like that.
Also the typical Members Name, Address, Phone Number, etc. Mostly this is a Data Storage and Retrieval app that facilitates reporting. Very little "processing" takes place and Nurses and Social Workers work in teams that are assigned members so I usually have very little crossover or potential data conflicts. Nurses and SW's also are responsible for different area's of the MCP(Member Centered Plan)
Additional question; Is Sync Framework really only a viable option if I can use SQL 2008? Seems that way due to the Change Tracking etc....thoughts?
Once you solve the problem of change detection and data movement, everything else is trivial. In other words technologies like WPF, Silverlight, Forms and even WCF are orthogonal to your main problem and your choice should be based on your personal preferences and experience. The real hard nut to crack is working disconnected and synchronizing changes. Which leaves two out-of-the-box avenues: Synch Framework or Replication.
I would say, for your scenario, definetely Synch Framework. Merge replication, like all forms of replication, is designed for systems that are connected continously with intermitent disconnects. And most critically replication can work only over static names. Laptops connecting from various hot-spots and ISPs have a nasty habit of changing FQ names with each connection. Replication can overcome this only if a VPN of sort is used and VPN is usually a major support issue. Replication is just not designed for the high mobility of OCA systems.
Synch Framework will pretty much force you to SQL 2008 back end because of the need to Change Data Capture or Change Tracking, both being SQL 2008 only features.
You will still have plenty of hard problems to solve ahead (authentication, versioning and upgrade, data conflict resolution policies, securing data on the client for accidental media loss etc etc)
Personally, I would say:
.NET 3.5
WCF Data Services (for communication between the client app and your data)
SQL Server 2k5/2k8 (whichever you can use)
Silverlight w/ Out of Browser Functionality
VistaDB (to store data locally on the client until you can push to the server)
use unique-identifier for key if you are creating stuff while offline and not connected and when you do connect, updating the database.
this is going to be way easier than using auto-increment key
Having worked on an occasionally connected application, I'd encourage you to look in to SQL Server CE for the client machines, with Sync Services to handle the connections. Here is a good tutorial.
You could create this stuff from the ground up, it seems.
However, this seems an awful lot like a CRM application, and it wouldn't surprise me if you could find an enterprise software package to do this without starting from scratch and instead modify one of the configurations to meet your business rules.
In a previous life, I was a configuration developer for this thing called Siebel that might be close to what your'e looking for. They even have a built-in synchronization tool called Siebel Remote.
It might be a cheaper route to go than rolling your own from scratch.
I wrote an order taking program for wine sales reps. Here is the video. The client software is installed using click-once. That also installs SQL Server Express and loads the database. I used the Microsoft Sync Framework to sync the local database with the one on the server (see the last section of the video.)
With powerful clients now I don't see any reason to not use SQL Server Express, it is free with a limit of 4GB.
SQL CE had too many limitations - no stored procs being a major one.
You will need to use GUIDs everywhere as the primary key - see the new NewSequentialID().
I love click-once, it is a big time saver.
I'm looking forward to Silverlight, but just haven't had time to look into it. Not sure if I would have done it with Silverlight if doing it now or not.
Having said all this, this is not a project for anyone inexperienced. So I would also get some very experienced help.