How would you formulate software requirements without saying: "The software has to know the filename of the configuration file."? You don't know yet if the configuration data will be held in a file a database or whatever may be decided later. So how would you generically refer to the address of this location without introducing technical constraints?
The configuration settings for the software should be stored external to the application, and the application should be able to access the external settings.
Related
I have an escenario i would like to discuss.
If i had a web app shared by several clients, everyone with their own database. In some time a client will report an error. How would it be the best way to handle this data?. Because im thinking on security implications that implies downloading a backup from clients and give to one developer to troubleshoot the erros.
But need this data in a real environment to reproduce the error. Any Ideas? Taking on consideration security implications that means the developer having access to all clients data.
Please have the client reproduce the error in their DEV environment and share the copy of the DEV database file with you. Your developers could then work with the data on the issue.
Kindly ensure the data being asked to share is not PCI or PII and in accordance to CPNA (if the client is US based)
that depends on the problem.
Usually the inserted, updated or deleted data have some kings that you can reproduce with a dummy database, with only one or two rows in each table and you have try to reproduce the error.
If you have good error logging feature, that saves in an text file or sqlite all relevant information like where the problem occurred and what was the cause. it will save you a lot of trouble.
If you need the database:
you restore the backup and replace all sensitive data with an UPDATE command and see if the error still occurs, before you pass the data on .
For that you can in advance write those update commands.
Some databases can encrypt also columns or obfuscate them, so you should see of your databse supports that and you can use it on the restored data.
I have been charged with determining the requirements to migrate data from applications running OpenVMS on DEC alpha. I have no knowledge of openvms or powerhouse, however, I have plenty of experience with linux. I am able to connect to the server via SSH.
My question is are there any standard tools part of openvms I can use to help me verify the database back end? get an idea of how many tables, rows of data, etc.?
What is the goal? Move the (structured) data over for once and for all?
Move application functionality over?
Move ongoing changes over?
You'll have to dig into the system to figure out what it does, what it is build upon. Is there no design guide, an operations play book, backup procedures?
Most likely it is based on RMS (indexed) files. The data file would be names .IDX, .INX, or .DAT or some such, and there would be mane files, one par 'table/object'. The procedures would table about BACKUP, and CONVERT.
There would be a PowerHouse Dictionary from which metadata can be extracted with "qshow generate file" into .ph files.
You may want to look at Attunity (I work there), Connx or Easysoft to use those definitions to provide ODBC or JDBC access to the data from the outside.
Attunity has tools to bulk unload into any target DB with 'one click' once the data definitions are in place, but it is likely too costly for one-time use.
Still, if the alternative is two months of consulting/coding then a tool may be attractive.
If it is based on RDB, then you would see a few .RDB files, .RBR and .AIJ files.
There would be .SQL script morcels and operations via "RMU"
Like any other database it would include metadata and has native option for remote ODBC, or (Oracle) OCI access
Hope this helps some,
Hein.
I am trying to develop a modular web aap using asp.net mvc 4. My question is that what is the best place to store the user settings, configuration and user access. Whether it is good to store it in db or good to store it in xml file.
I would prefer to go with XML.
Advantages in XML file :
No need to access in your database server.(Which is contains valuable data)
Anybody can understand and change the settings. (No need to know about SQL)
Platform independent.
Disadvanges in XML file :
Need to backup the file. To overcome this problem, Have to maintain the changes by history (It is a best way to revert it back).
I have a vb.net windows form application with a database on SQL Server 2008 on the ./SQLEXPRESS instance.
I have created a setup of my project using the link below..
http://msdn.microsoft.com/en-US/library/49b92ztk(v=vs.80).aspx
When a user installs my application, the database will be available for him, and user can just export the SQL Server database.
How can I secure my database so that user shouldn't have a easily available copy of my database?
I thought of creating a new password protected server (as I have created the database in above walkthrough)... while installation of my application on user's pc, other than ./sqlexpress. And a complete copy of database used by my application will not be simply available for user to just export and get a copy of my database.
So could anyone please guide me...
The question is; how far do you want to go to protect your data?
Better protection of your data usually comes at the cost of more development time and likely less user friendliness, for example due to lower performance (encryption is not free). More complex code usually results in more support requests too.
Where the best balance is depends on your business model (if any) and on your user requirements.
Keep in mind that anything you deploy to an end-users machine is in the end vulnerable. If something is valuable enough there will be people trying to steal it.
So, you could argue that the best protection is not to deploy the data at all. You could back your end-user application with a web service and keep the data on your own server, for example in the cloud.
I've found however that you sometimes just need to trust your users. If you build a good product that makes them happy, they have no reason to steal from you. In fact, they are probably glad to pay you.
If you decide that you need to deploy the data and that you need to encrypt it, you should think about why you chose SQL Server.
What database features do you need exactly? Do you need a fullblown database server for that?
Any local admin can gain control over any SQL Server database in seconds so the built-in SQL server authentication will not bring you a lot of benefits.
You could switch to SQLServer CE and keep the database within your application. That would make the database a lot harder to access for a regular user.
If all you're doing is looking up words, you may be better off with a different storage engine like Lucene.
Lucene is actually a search engine, so it's highly optimized for matching words or parts of words.
You can run Lucene inside your .NET application so you don't even need the end-user to install SQL Server. There is a .NET version of Lucene here.
Lucene however doesn't protect your data. There's tooling available that will allow anybody to view and extract the data from the stored index files.
Since Lucene is open source though, you could extend it to support encrypted data storage (see this related question).
I have a situation were I need to reference a schema in two different BizTalk applications.
I could either:
Put the schema in one application and make the other applications have a reference to it.
OR
Put the schema in a common application and all other applications have a reference to this common application.
However, in both the above cases if there are any changes to the schema I end up having to rebuild/redeploy all the applications having a reference to the schemal. Is there a better way of organizing the applications?
From the Microsoft Biztalk Operations Guide:
Deploy shared artifacts in a separate application - If artifacts are going to be shared by two or more applications, deploy the shared artifacts into a separate application. For example, if two applications share a schema, place the schema in a separate application. We recommend this because only one artifact in a BizTalk group can have a single locally unique identifier (LUID). A LUID consists of the artifact name and optionally other attributes. If you include an artifact in one application, and then create a reference to it from another application, the referring application may not function correctly when you stop the application containing the artifact.
This best practice applies to all artifact types except for files, such as Readme files and scripts, which are added to the application as a File type of artifact. This is because more than one file artifact with the same name can be deployed in a BizTalk group. Therefore, you can use a file having the same name in two or more applications. In this case, stopping one application will not impact the other application. For more information about adding file artifacts, see "How to Add a File to an Application" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=106818.
The schemas going in the shared app really shouldn't change as they're shared and this is a major event. If you are adding schemas or modifying existing maps, there is no need to rebuild old apps. You may have to recycle dependent host instances to get them to refresh their in memory copies of the dll. Otherwise should be 95% hassle free.
We put our common schemas and functionality into a separate application.
I am not sure im understanding your question, so correct me if i am off base.
You should organize your schemas as their own assembly that can be independently deployed to all the applications that need it. They can then be referenced by other projects during development. After deployment if changes are made to the schemas; the schema assembly just has to be updated on the server; the reference to the schema from the applications will be maintained.
hope this helps.