For those new to message boards please try to follow a few simple rules when posting your question.
Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode "<" (and other HTML) characters when pasting" checkbox before pasting anything inside the PRE block, and make sure "Use HTML in this post" check box is checked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question into an unrelated forum such as the lounge. It will be deleted. Likewise, do not post the same question in more than one forum.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
There is a lot of talk about it on my radar. I just implemented it on a .Net Core 2 Angular App.
I'm not sure what to think of it yet, still too early as I've only written 15 records or documents to it.
Very different indeed.
I like the part where I didn't have to create the table, and was able to just write to it.
I'll have to write the Angular backend to it first so I can read the data.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
Would I have to use gridFS to store images, for the 16mb limit
Yes, that is basically the point.
However that isn't really the differentiator. If you are storing binary data of any sort then you only have two options: encode it (like base64) or store it in gridFS.
If I needed to store streaming video, for example from a security camera where I need to keep the data for long periods of time and provide a way to sequence through it with time searches then I would at least consider Mongodb as a strong contender for just storing the video. I would test it but I presume it is adequate. Although excluding other business needs I would also look into cloud file storage as well (security concerns might preclude the cloud.)
Also for large documents. A MongoDB cache can span several computers, making it ideal for static blobs that are to be served
Where "large" means what exactly? I was working with a Mongodb instance that would serving up to 100 mb documents although normal ones probably ranged from 100k-2mb.
I didnt' do much to specifically manage that.
At least at one point I was managing documents on a SQL database (Oracle I believe) where the documents were stored in the file system and the database only kept a URL. That of course is exactly what I am doing now with AWS cloud and S3 storage.
If you do not know SQL and do not want to know SQL then it works.
In large business application domains it will not be adequate. But those often use disparate and not complementary technologies anyways.
NoSQL **DOES NOT** eliminate the need to manage the database. Never sure where people come up with this claim. Probably because they only use it for toy applications. ANY persisted data store will, over time, require maintenance. Things change over time and that means the data store(s) must be modified to fit those changes. And nothing fixes that.
Ignoring the need of future modifications only makes the need when it arises more difficult.
Getting the data model right is a problem unless you have experience in the business domain. Correcting the data model with NoSQL falls into the problem that I discussed above and certainly seems harder to me in NoSQL. But then I have been using SQL for a very long time so creating such solutions via SQL are going to be easier for me.
NoSQL has no advantage over normal business entities. Things like users, accounts, etc. Again that is more based on longer term business needs and because there are many, many tools that exist to use SQL and thus use such entities. For example to make money account might want to query the customers in the database - via SQL. Since NoSQL has no standards for API the usage of such tools for NoSQL is not as complete. But Mongodb has the advantage that it is the leader so such tools might support it.
Constraint violation is severe problem in NoSQL. It is a severe problem in SQL as well, unless you add the constraints in the first place. And doing that right can be complicated. There are no transactions either. Which means you need to deal with rollbacks if there is an end to end problem. Not an insurmountable problem unless you don't plan for it in the first place. But incorrect usage of transactions can lead to weird and very hard to deal with problems in SQL.
In one Mongodb application I considered that the only way to fix the constraint and transaction problem was to write a server that wrapped it and presented a standard API. It would manage transactions, rollbacks and constraint checking. Of course at that point what I would have had was in fact a relational database (so pointless to have NoSQL.)
I like SQL Stored procedures. Can't speak to any NoSQL solutions except Mongodb but their solution I do not considered a swap in replacement for stored procs. It is more just a way to moved normal business processing to the Mongodb server.
I've been using SQL for over a decade, and NoSQL is sort of a head scratcher to me.
I'm just using it for training on my personal website to see what it's all about. See why it's on so many job postings. I currently use SQLite on my personal website on .Net Core 2.1 and it works great.
But MongoDB seems lightweight and can be used by any project that has access to it, which means I can use it from Docker Containers. Not sure how to use SQLite from Docker Containers.
Currently, I'm just storing contact messages from contact us. was going to try reviews and portfolios which would be more complex and your right, I would have to get the class model right in order for portfolios to work. I may give up on it and go back to SQLite.
Overall, this Angular 6 project wrapped in .Net Core using MongoDB has been a pain in the butt.
Now I see why there are so many job postings for the .Net Core Angular 6 person with MongoDB a plus. It may not be achievable on an industrial scale.
I can see storing Countries, States, Notes, reasons, selections on it to take the load off a SQL server.
If it ain't broke don't fix it
Discover my world at jkirkerx.com
Personally I would have single transaction table with a transaction type column but each to their own.
Whether you follow my advice or not, you will need to JOIN the tables based on the column that is common to all of them ID_Provider or Name_Provider if you leave things as they are. Here is an article that tells you how to do that Joining Tables in SQL[^]
Note we are referring to "SQL" in the sense of T-SQL - the "language" and not SQL Server the database. As you are connecting from VB.NET to Access I presume you are using ADO or OLEDB - both of which will require SQL statements.
Once you have worked out how to join your tables you already have the SELECT clause essentially written...