Please suggest a easy method to take backup of P6 application configuration details(configuration and authentication tab).
I need to take backup of this configuration before importing production data into the develpment environment. Currently i am taking screenshots of each options which is very exhausting.(I'm new to Primavera). Please help.
It looks like the configuration data is held in the ADMIN_CONFIG table. If you are using SQL Server you can use the SQL Profiler to watch the queries being issued by the admin tool.
Related
Made a mistake with mysql restore on the production site instead of the staging one. Can I use mysql general log to restore? It seems general log is all I have. I dont seem to have a binlog with MariaDB's Aria storage engine.
What should I do now? Anyone has any experience using general log to recover the database?
I need to migrate a customer's site which happens to be hosted in a remote Win32 environment with Sitebuilder, Plesk, SQL Server and ASP or ASP.Net, I'm not sure.
I'm used to LAMP environments, so I don't know what to do with all the files in this server. Sitebuilder and SQL Server are also new to me.
I only have access to the FTP files and to the Plesk panel control, but it doesn't even acknowledge the existence of any SQL Server database (as it usually does with MySQL databases).
So far I've only been able to think of these two options:
Code an ASP script that writes down the database content into CSV files (wouldn't know where to start).
Code a script that retrieves the data directly from the HTML pages (long, painful, error prone and not useful to access data available only to logged in users).
So my question is: from your experience, knowledge of this platform, and point of view, which would be my best option?
Thank you very much in advance in my first question here. Regards,
UPDATE: I've managed to access the server (Windows 2008 server + SQL server 2008) using remote desktop. I guess I should be able to export the database now. I'll check Management Studio to see if it can help in the process.
It sounds odd that it doesn't support remote connections, but if you want to do it from within your asp-pages, the following links might be good starting points:
Want to script all objects which depend on a SQL Server table
http://www.dotnetfunda.com/codes/code32-how-to-generate-create-table-script-for-all-tables-in-sql-server-database.aspx
https://dba.stackexchange.com/questions/20355/generate-create-script-for-all-indexes
I have been using a central MS SQL database located in the cloud to develop a web site project. I have recently found myself in situations, when I need to develop without the internet connection. I want to begin to use a locally available copy of the existing database, put it in App_Data folder.
What is the correct set of steps I need to undertake to get the project to work with local DB?
For example:
Detach a db from an existing SQL instance.
Copy to a development machine.
etc.
Moving a SQL-Server DB is not that hard. Look here for some methods to do it.
http://support.microsoft.com/kb/314546
I usually find the sp_detach + sp_attach method really easy.
I would create an empty shell database locally, then use one of the many schema comparison solutions available to make the local database look exactly like the cloud database.
Correct way is to create and regularly update your standalone copy of database using import/export. In particular MS SQL Server provides Import/Export Wizard tool for such purpose.
Make a backup
Copy backup file
Restore on your server
Restore/organise users
I have an application written in ASP.NET and using EF. I want to make a copy of the live database, have my application point to the copy, and be able to run the application against it as if it is live...but making updates to the copy.
I know I can manually copy the database and manually update the web.config files...but I'm wondering if there is a better, more automated method for achieving this with VS 2010?
Also, if there is anything I need to know about setting up a live/dev version of a database while using EF4.
You can switch the ConnectionString to point to the live or development database.
One way is to have different web.config files for debug and release builds.
Check out Web.config Transformation Syntax for Web Application Project Deployment
From my experience,
Setup 2 database connection entries in your config file, name one backup and leave the other ones name alone. Point your backup one to the backup db and when you want to run the backup, just change the names of the entries so the backup one is the actual name and the live one is named anything else.
Also, as for setting up different db versions - I'd just be careful that you don't update live by mistake!! and I've found it best to track changes to the db structure in a sql file so the live can be updated if needed or the backup can be rolled back if changes are made
I am building a blog-like publishing system on ASP.NET 4.0 (with EF 4.0) that I want to be very easily deployable/backupable in the first place. I am at a decision point of whether making the system to create a database in an SQL Server and use that (traditionally), or have a App_Data MDF file in the site and just attach to that one with SQL Express. I know the memory/size limitations of Express editions, and I won't be hitting the limits as this is not a performance-critical business application or any serious stuff. Just a simple CMS with blogs/writings/photos (actual photos are NOT saved in database, just their paths are saved in MDF) and that's it. I see no problem using MDF, but I'm not an expert on the topic too as I've never worked/created a website using MDF file. I always deployed on the SQL Server, but I don't want to deal with users/roles/permissions and the last thing that I want to have a user having installation problems due to database settings.
What should I go with? Any problems that I would face with MDF? Recommendations?
IF you use SQL Server Express - which is a server - I would always opt for a "real" database approach: attach your database to the server, access it by its database name, deploy SQL scripts to update it.
That "attach DB from file path" always seemed like a half-baked and rather messy kludge to me.....
If you don't need that kind of power - investigate SQL Server Compact Edition which is a one-file only, in-process database. It has its limitations - no stored procedures, doesn't support certain data types like VARCHAR(MAX) or XML - but for easier scenarios, it's perfect and easy to use - just deploy it along your app. It's single-user, e.g. you don't share the data between several clients, it's a local store for each user/app on its own