First of all, switching to datastore2 won’t fix data not saving. It just uses Datastore. If you’re using Datastore correctly and it still doesn’t work, that means datastore2 won’t fix it either.
If you have been testing this in Studio you will need to allow Studio to access API requests in your Game Settings. Also, I suggest you wrap your datastore requests in a pcall since any API requests can error unexpectedly and without a pcall your whole script will stop.
Technically it would. The error here is that PlayerRemoving is never being fired. You can add a print statement and test it too you will see. Add a BindToClose Event to fix this. Also if you test on an actually server it will work.
Don’t use datastore2 just because people say it works - the bereza method isn’t perfect. Learn what it does exactly before you use it. It uses datastore, not some external database.
If all datastores are down, it will still result in data loss. You can minimze it, but there’s nothing you can do to prevent it.
Have you only been testing this in Studio? Since I have heard that datastores seem to not be as responsive in studio compared to playing on a game server.
Then what are you saying i should do? what you said are just not contributing to what i need help with right now. You are just talking about how datastore2 is unreliable.
simple as a yes or no answer, yet you keep saying im going to use datastore2 or whatever.
EDIT: didn’t see you post there as they were both posted at the same time.
First you should read the advice I gave you and then look at the devforum post I linked. It’ll help you decide if you want to use datastore2.
Here’s why i told you not to use datastore2 without knowing how it works:
Just joining the crowd without doing your own research is bad. I’m trying to prevent you from just using datastore2 without knowing what it does internally, because too many people use it without knowing how it works.
So it’s not a simple yes or no answer like you asked for. That’s why i’m not giving you a simple yes or no answer, and its why i linked the devforum post.
Like i said: I never stated that i was going to use it without any knowledge on it.
You keep saying i was going to use datastore2. You are missing half of the point in this topic. I need help with my CURRENT datastore problem, which is not datastore2.
Instead of saving each value on 2 different stores, just save it on 1:
local Key = player.UserId
local Data = {
Level = leaderstats.Level.Value,
Coins = leaderstats.Coins.Value,
etc.
}
local Success, ErrorMessage = pcall(function()
MyDataStore:SetAsync(Key, Data)
end)
And then you would load data like this:
local Key = player.UserId
local Success, Data = pcall(function()
return MyDataStore:GetAsync(Key)
end)
if Success then
if Data then
Level.Value = Data[“Level”]
Coins.Value = Data[“Coins”]
etc.
end
end
Most likely the problem is that the server has already closed before the data could save. The solution is to use game:BindToClose() and wait until all data is saved.
The way i do this is have a variable that tracks the amount of data that has to be saved. In game:BindToClose() i simply wait for the variable to become 0
I believe limitations is the word you’re looking for, DataStore2 is just another DataStore system, I don’t see how it can have any detrimental effects . The post you linked is outdated by the way and DataStore2 now does support the usage of promises; GetAsync() and SaveAsync() exist now. Go see for yourself.
As for the topic, @dibblydubblydoo you’re doing several unnecessary things here: You don’t need to have separate DataStores for each different data type, try to save or essentially combine all your data under one dictionary instead , this will save your DataStore Get and Update/Set request budget significantly.
Now for an answer relevant to the contents of your post:
You asked for whether it is advisable or not to use DataStore2 to prevent errors, the answer could be any, only you can decide whether it meets your needs.
DataStore2 has received commendation from many, proper usage of it could lead to virtually no data loss, that’s what it’s built for. Quenty’s system is reliable too, use whatever system you feel has an easy to understand API and meets your needs.