Share this post

Link to post

Share on other sites

JLogan3o13 1,375

JLogan3o13 1,375

And I am saying, it depends on what you are doing. If you're writing a script that needs to just pull date and time, pull it from the local system. If you need something that pulls across time zones, use GMT. You have to be more specific, as there is no single answer for all circumstances.

Share this post

Link to post

Share on other sites

KickStarter15 24

KickStarter15 24

Not sure if I get it correctly of what you meant. Here's what I though, I'm currently in a company right now that has storing, loading, extracting data and we usually load it from the server, we are not loading it from INI file. There are cases that loading it in INI file might be risky from both parties and some might have corrupted it in their local system and can cause big issue.

Just a heads up, every data that you load must be secured by adding some code of restriction/admin... etc...

KS15

Programming is "To make it so simple that there are obviously no deficiencies" or "To make it so complicated that there are no obvious deficiencies" by C.A.R. Hoare.

Share this post

Link to post

Share on other sites

LerN 3

LerN 3

Not sure if I get it correctly of what you meant. Here's what I though, I'm currently in a company right now that has storing, loading, extracting data and we usually load it from the server, we are not loading it from INI file. There are cases that loading it in INI file might be risky from both parties and some might have corrupted it in their local system and can cause big issue.

Just a heads up, every data that you load must be secured by adding some code of restriction/admin... etc...

KS15

Can u give me some information about the servers, can i use it to load big data?

Edited July 13, 2017 by LerN

Share this post

Link to post

Share on other sites

SlackerAl 28

SlackerAl 28

I find I have a few minutes... perhaps this example of how a program might use stored information will help you:

Consider a company that makes cars. A purchaser, called Fred wants to be able to examine how many parts are required to make various systems for a car and asks a developer to write a program to help him.

Version 1
The program stores all the information about the parts and which system they belong to in a csv file on Fred's desktop. Each time Fred wants information on a system he types its name.

Version 2
Fred is pretty happy with this, but is getting bored of typing in the name of the powertrain system everytime he starts the program (because most of the time he is looking at powertrain components). The developer then adds a default system to open when the program is run. He stores this information in a local .ini file so that Fred can change his initial system if his work demands change.

Version 3
Fred loves this and gives a copy to his colleague Bob. Bob loves it and gives a copy to his colleague Jim. Everyone still keeps their local .ini file because they all have different requirements for a default setting.

Then engineering tells Fred that some of the parts have changed... and Fred realises there are uncontrolled and unmaintained copies of his data everywhere. Fred is sad and tells the developer what has happened. The developer suggests they store all of their data on a centralised file server, then there is only one file to maintain. A quick code change and a file copy and all is well. Everyone is now using one file that Fred owns and maintains on a remote server.

Version 4
The developer is sacked and replaced by a developer who explains this should all have been done using an SQL database instead. The local .ini files can be replaced by user accounts and preferences incorporated into the database.

Finally the database corrupts and everyone is sacked because there was no backup strategy.

Whether you use a centralised server depends on the program and the users. How much data is stored is a function of the program and the users, this needs to be planned for. There are many issues associated with multiple access requests to served data, but I think that is a discussion for another day. The summary is, use an ini file to store local configuration data, everything else depends on requirements.

You can easily experiment with "large" data sources by creating a local SQLite database and filling it with random data. Understand local problems before you start to bring networks and multiple users into it. Check the help manual on _SQLite_Startup and follow that for a bit. SQLite is not a true server, but it will be an easy way to get a feel for one.

Share this post

Link to post

Share on other sites

LerN 3

LerN 3

Look bro i am not actually doing projects in autoIt but somehow i wanted to ask some questions about what developers do when they get a job or something like that
What i meant is an company asked this developer to do an project for them and this company wants in list view names , age , code , telephone , notes and address etc
and there's more that 8000 person will be showed in this list view so how do they load the names and age , code etc
From ini files ? "Not Safety if something bad destroyed the hard"
or from SQL server ?

Edited July 13, 2017 by LerN

Share this post

Link to post

Share on other sites

iamtheky 771

iamtheky 771

dont bro people here, lest you find out you are talking to a woman. It is very much you who is asking an incomplete question.

If you have name/age/defining chacteristic (PII) stored in an ini, chances are you are not any kind of company that is audited or regulated, and if this was prod they would most likely not have SLAs or data handling controls in place.

At the very least you sit that data in a database optimized as a KV store like mongo, bro.

Share this post

Link to post

Share on other sites

Skeletor 56

Skeletor 56

Another thing is if the data would need to be accessed without having to use the database or creating a read only user for example SSMS, then they would use IIS services and a web interface to access this information.
Other than that, if you need to also insert the information, you can also use the web interface to do so. Just think about how you log into facebook, its the back end that does all the work...