Database giving out wrong data

The goal is to save some of the settings the player can set in the game.

I have little experience in databases and I really can’t figure this thing out.
The script is this:

local DataStoreService = game:GetService("DataStoreService")
local LocalizationService = game:GetService("LocalizationService")
local RS = game:GetService("ReplicatedStorage")
local playerData = DataStoreService:GetDataStore("ExcursusData")
local Players = game:GetService("Players")

--local success, removedValue = pcall(function()
--	return playerData:RemoveAsync("Player_1175598905")
--end)
--if success then
--	print(removedValue)
--end

local function onPlayerJoin(player)  

	local storage = Instance.new("Folder")  
	storage.Name = "PlayerData"
	storage.Parent = player

	local VC = Instance.new("StringValue") 
	VC.Name = "SettingsVC"
	VC.Parent = storage

	local SettingsGQ = Instance.new("StringValue") 
	SettingsGQ.Name = "SettingsGQ"
	SettingsGQ.Parent = storage

	local playerUserId = "Player_" .. player.UserId  
	local data = playerData:GetAsync(playerUserId)  
	if data then

		VC.Value = data
		SettingsGQ.Value = data

	else

		VC.Value = "PART"
		SettingsGQ.Value = "MED"

	end

end



local function onPlayerExit(player)
	local success, err = pcall(function()
		local playerUserId = "Player_" .. player.UserId

		playerData:SetAsync(playerUserId, player.PlayerData.SettingsGQ.Value)
		playerData:SetAsync(playerUserId, player.PlayerData.SettingsVC.Value)

	end)

	if not success then

		warn('Error saving data!' .. tostring(err))

	end
end


game.Players.PlayerAdded:Connect(onPlayerJoin)

game.Players.PlayerRemoving:Connect(onPlayerExit)

game:BindToClose(function() -- (only needed inside Studio)
	if game:GetService("RunService"):IsStudio() then
		wait(3)
	end
end)

And it goes like this when I test:

  1. I uncomment the function above to remove my data before entering.

  2. Play the game, and no folder PlayerData shows up, which I think is ok.

  3. Stop the game, comment the function, and play again

  4. Folder shows up normal, I edit the values inside of it to see if they save (The values indeed are “MED” and “PART”, just like they should be):
    image

  5. Stop the game and play it again.

  6. Both values are now set as “PART”, like how?

If anyone has an idea on what’s happening, I would really appreciate it.
And I am planning on adding more values, so yeah please be aware of that.

You’re overwriting the same key. Instead, you should save the player’s data in a table:

playerData:SetAsync(playerUserId, {
    GQ = player.PlayerData.SettingsGQ.Value,
    VC = player.PlayerData.SettingsVC.Value
})

Then, you can access the indices the same way you would do so for a normal table:

VC.Value = data.VC
SettingsGQ.Value = data.GQ

You should also wrap your GetAsync call in a pcall because if it fails and errors, your StringValues won’t have any default values set.

I’ve changed the script sections you corrected, but after testing for the first time it printed an error something like “… string expected, got nil”.

I thought it was something with changing the script so I manually changed the values, and stopped the game.

Every next playtest printed out no errors, but the values were always blank every time I tested.

That’s the script I now changed, have I missed something?

local DataStoreService = game:GetService("DataStoreService")
local LocalizationService = game:GetService("LocalizationService")
local RS = game:GetService("ReplicatedStorage")
local playerData = DataStoreService:GetDataStore("ExcursusData")
local Players = game:GetService("Players")

--local success, removedValue = pcall(function()
--	return playerData:RemoveAsync("Player_1175598905")
--end)
--if success then
--	print(removedValue)
--end

local function onPlayerJoin(player)  

	local storage = Instance.new("Folder")  
	storage.Name = "PlayerData"
	storage.Parent = player

	local VC = Instance.new("StringValue") 
	VC.Name = "SettingsVC"
	VC.Parent = storage

	local SettingsGQ = Instance.new("StringValue") 
	SettingsGQ.Name = "SettingsGQ"
	SettingsGQ.Parent = storage

	local playerUserId = "Player_" .. player.UserId 
	local success, err = pcall(function()
		local data = playerData:GetAsync(playerUserId)  
		if data then

			VC.Value = data.VC
			SettingsGQ.Value = data.GQ

		else

			VC.Value = "PART"
			SettingsGQ.Value = "MED"

		end
	end)
	
	if not success then
		warn('Error loading data! ' .. tostring(err))
	end

end



local function onPlayerExit(player)
	local success, err = pcall(function()
		local playerUserId = "Player_" .. player.UserId

		playerData:SetAsync(playerUserId, {
			GQ = player.PlayerData.SettingsGQ.Value,
			VC = player.PlayerData.SettingsVC.Value
		})

	end)

	if not success then

		warn('Error saving data! ' .. tostring(err))

	end
end


game.Players.PlayerAdded:Connect(onPlayerJoin)

game.Players.PlayerRemoving:Connect(onPlayerExit)

game:BindToClose(function() -- (only needed inside Studio)
	if game:GetService("RunService"):IsStudio() then
		wait(3)
	end
end)

Which values did you change them to in particular?

The error may have stemmed from the fact that the player’s data was still a singular string and the script was trying to find a function or property of it.

Also, make sure you’re editing/changing the values from the server and not the client

I just set the values in the properties to “test” when in playtest mode under Players.iihelloboy.PlayerData.SettingsGQ

Can it break because of this?

Not necessarily, you just have to make sure that you’re modifying the values on the server side instead of the client side.

If you modify the values from the client, the server won’t see the changes and the values will remain blank

Well was what I did from the server’s side or from the client’s?

It depends on whether or not this:

Says Server in your studio Topbar under the Home tab:

If it says Client, click on it and it’ll switch, then Edit the values from there


(Studio Testing Modes | Roblox Creator Documentation)

1 Like

Oh, that, well yes it was always on the client, that was apparently the reason.

And it works perfectly now actually, thank you for that!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.