Datastore doesnt save

hey, my datastore doesn’t save on leave. is it because it loses data? so is it better if I switch to datastore2?

nothing is wrong in the output.

local dss = game:GetService("DataStoreService")
local data = dss:GetDataStore("data")
local data2 = dss:GetDataStore("data2")

	local leaderstats ="Folder",player)
	leaderstats.Name = "leaderstats"
	local HotCoin ="IntValue",leaderstats)
	HotCoin.Name = "Hot Coins"
	HotCoin.Value = data:GetAsync(player.UserId) or 0
	local Hotdog ="IntValue",leaderstats)
	Hotdog.Name = "Hotdog Eaten"
	Hotdog.Value = data2:GetAsync(player.UserId)

	data:SetAsync(player.UserId, player.leaderstats["Hot Coins"].Value)
	data2:SetAsync(player.UserId, player.leaderstats["Hotdog Eaten"].Value)

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.

1 Like

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.

1 Like

Also, you shouldn’t create a seperate datastore for each value. You can save tables.


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.

1 Like

There have been reports of people using datastore and losing data, however switching to datastore2 fixed it.

please read the post @xZylter, I have stated that nothing is wrong with the output and that API access is on. :slightly_smiling_face:

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.

I never said I was going to use it. If I shouldn’t use it because it works, then what would I use lol?

i also, never said i didn’t know how to use 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.

If I shouldn’t use it because it works

What? this isn’t what i said at all.

i didn’t know how to use it.

same here. I said learn how it works, not how to use it. Two completely different things.

yeah, you did actually.

pretty sure you said both of those things.

Nope, that has nothing to do this this: “If I shouldn’t use it because it works”
If you want to argue about this, you can go to my dms.

This devforum post explains the disadvantages of datastore2 pretty well.

Yes it does, because it is really similar. if not, i don’t know what you were talking about.

Back to the original question:

  1. Don’t use the parent argument on Instead, manually parent it afterwards.
  2. Don’t create a seperate datastore for each key. Use a table, update the keys in that, and save the table into 1 datastore.

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,
local Success, ErrorMessage = pcall(function()
    MyDataStore:SetAsync(Key, Data)

And then you would load data like this:

local Key = player.UserId
local Success, Data = pcall(function()
    return MyDataStore:GetAsync(Key)
if Success then
    if Data then
        Level.Value = Data[“Level”]
        Coins.Value = Data[“Coins”]
1 Like

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

1 Like

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.