I want to store basic information for a action script flex app. Normally I would just have a simple application.ini file where this config resides. Is there an inherent way that I can store this kind of information so that when I close an application and open it again, it knows what I changed a variable to? Ideally, without having any config files lying around? Perhaps it can store it in registry or another way?
Ideally, without having any config files lying around?
Shared object will help you to store some information. I don't know how big is your data, but SharedObject is great for storing flags and states.
The SharedObject class is used to read and store limited amounts of data on a user's computer or on a server. Shared objects offer real-time data sharing between multiple client SWF files and objects that are persistent on the local computer or remote server. Local shared objects are similar to browser cookies and remote shared objects are similar to real-time data transfer devices.
Related
This isn't exactly a question in need of help, however, I am curious as to which file is updated, when updated, when I use Heroku via Github. Would it be the one within my Github or does Heroku save those files and update them somewhere else?
All I'm trying to accomplish is edit a JSON file so I can store an integer to each player (I'm using a worker, for a discord bot). Also, yes, that seems like what I am trying to do. Anything that saves the information, doesn't require money and isn't too complex
EDIT:
This issue has been solved with the answer that Heroku simply cannot update JSON files. I have resolved it myself by moving my host onto a Raspberry Pi 3 Model B+. Thank you for all the answers.
When you use Heroku's GitHub Sync feature, a deployment will retrieve your code directly from GitHub.
Those files aren't saved anywhere else. A new deployment from master will take the code fresh from GitHub.
All I'm trying to accomplish is edit a JSON file so I can store an integer to each player (I'm using a worker, for a discord bot). Also, yes, that seems like what I am trying to do. Anything that saves the information, doesn't require money and isn't too complex
Heroku's filesystem is ephemeral. Any changes you save to the local filesystem will be lost when your dyno restarts, which happens frequently. If you scale your application to multiple dynos you'll also run into trouble since the ephemeral filesystems are dyno-local.
Your best bet is to use a proper client-server datastore, like PostgreSQL. Heroku provides its own Postgres service, which has a free tier. If Postgres isn't to your liking, feel free to choose something else.
I need to develop a very simple database (probably no more than 4-5 tables, with up to 50 records per table) for my company, with the following requirements:
The database itself (most likely an Access file) must be stored on a server and accessed through http://www.something.com/my_db.mdb
Users from 6 different countries (with generally low Internet bandwidth) must be able to access this database and to view / edit it through a few masks, as well as produce automatic reports / extracts
The whole solution must be as robust and as low-tech as possible, to reduce maintenance issues (ideally, no development at all)
I cannot pay an Access license for each user, and using OpenOffie or LibreOffice is not an option (because I cannot go and install it on the computers of all the users)
My first (and naive?) idea was to:
1) Create the mdb file containing only the data and store it on a webserver
2) Create the edition masks and the automatic reports in another file that would define the online file as data source
3) Deploy the file containing the edition masks to the computers of all users
4) The users only have to open their local file to edit the distant DB through ther edition masks
Is my approach somehow realistic? Do you see another approach that would make more sense? Can I implement my solution with 1 single Access license?
Thanks a lot in advance for your inputs and insights!
If you provide just the mdb file as file source, accessible via HTTP, the users won't be able to connect to the database, because in a HTTP GET file download they just get the .mdb file downloaded to their local computer. When they edit something within the database (e.g. add a record), it will be done just locally on their local copy of the file.
If you want to use a access database, the simplest approach I have is that you implement a very small web application (e.g. ASP.NET) which connects to the .mdb file (and the .mdb file then can be in a private directory on the server). Your web application then is deployed to Internet Information Server (Microsoft IIS as a webserver).
You can provide data forms as web application, which you implement using ASP.NET, or develop separate clients which access web services you develop with .NET.
You could try cloud based solutions like; Google Firebase
For a requirement of this type; one should not use Access tables which are static because Access is a front end database but instead use a back end database such as SQL Server Express. SSE is free and one is better positioned to provide real web based features if needed in the long run.
Further I would say, in terms of cost/management - one should really consider using one of the online db services such as soho, knack, airtable, etc. One of these could well be faster and less expensive than creating a web app from scratch for such a small requirement.
I have a flash application which runs on web. I need to store images and audio files onto the clients local disk(don't want to store on web) without prompting the client. I have already tried with shared object. But since shared object space is limited to 100 KB per domain I am searching for alternatives.
If someone has better solutions please let me know.
Thanks.
You can't do this with the Flash Player by itself. SharedObject and FileReference/save() are intentionally designed to allow the user to have authority over local storage. It would be a security concern if users did not.
Using an AIR application, though, you can do this using File and FileStream, or EncryptedLocalStore.
I had the same problem with creating log files and writing to them
The only solution for me was to create a localhost WebService (used WCF), so i could use URLRequest to the localhost and pass data to service - which then updated file or created it.
But in your way, if you want to store things from the user to your disk, maybe you could also somehow play with the Web services. Just need to try.
Visual studio has almost complete Web service template - just edit for your purposes.
I have a node.js application that uses a simple JSON file as the model. Since this is an MVP with very limited data storage needs, I don't want to spend time designing and configuring a MongoDB database. Instead, I simply read from and write to a JSON file stored in /data directory of my Node JS application.
However, on Heroku, the JSON file appears to get reset (to the original file I'd deployed to Heroku) every so often. I don't know why this happens or how to turn off this behavior. Any help would be really appreciated, I need to fix this problem within the next four hours.
Heroku uses an ephemeral file system, so that's why it's going to vanish (every 24 hours, or thereabouts).
If you want to store something, you have to use an external backing store. Adding a free tier MongoDB database shouldn't take more than a few minutes. See here or here for examples.
What are the benefits of choosing either:
a file in the user's home directory, e.g. ~/.myapp/config
using the user's gconf database
I already know a couple of things; storing data in the user's gconf database makes it a little harder for the user to copy those settings out and onto another account or computer. On the other hand, is it true that using gconf would be easier as the underlying data storage facilities are already sorted out, without you having to write your own configuration file handler?
I'd go with GConf.
However...
Perhaps if you are worried about users copying their settings in and out of the program, you should create import and export settings functions into your program? A user could then potentially save those settings in cloud storage like Ubuntu One or Dropbox and simply import their desired settings into GConf using the utility that you provide, regardless of the machine (even if they prefer to run from liveCD). Either way, very clearly indicate to the user where the settings are being stored. Many (but not all) Ubuntu users are comfortable backing up and restoring those configuration files by themselves using rsync or another backup utility.
Go with GConf. It was designed to store configuration for programs, and that is what you should use it for. Why should you re-invent the wheel from scratch when you have a perfectly good wheel making device in front of you?