Resolving Dependency Conflicts:
Using maven, it is inevitable that two or more artifacts will require different versions of a particular dependency.
To manually resolve conflicts, following steps give very useful information:
(1) build the top level deployment by using:
$mvn -o -X test
this command will list all dependence information.
(2)grep the output of step (1) and remove the [DEBUG] at the beginning of each line
(3)sort the output of step (2), then you can find out easily the version conflicts.
Friday, August 17, 2007
Saturday, August 4, 2007
how to automate postgresql maintainence
Assume that postgresql is installed in /usr/local/pgsql directory.
$crontab -e
22 3 * * * su - postgres -c "/usr/local/pgsql/bin/vacuumdb -a -f" >> /var/log/vacuumdb.log 2>&1
23 3 * * * su - postgres -c "/usr/local/pgsql/bin/pg_dump -Fc -b -f /tmp/db.sql db" > /var/log/dump.log 2>&1
and then save like under vi editor.
$crontab -l
to list the task
$crontab -e
22 3 * * * su - postgres -c "/usr/local/pgsql/bin/vacuumdb -a -f" >> /var/log/vacuumdb.log 2>&1
23 3 * * * su - postgres -c "/usr/local/pgsql/bin/pg_dump -Fc -b -f /tmp/db.sql db" > /var/log/dump.log 2>&1
and then save like under vi editor.
$crontab -l
to list the task
Friday, August 3, 2007
How to Change the Timezone in Linux
1. Logged in as root, check which timezone your machine is currently using by executing `date`. You'll see something like "Mon 17 Jan 2005 12:15:08 PM PST -0.461203 seconds", PST in this case is the current timezone.
2. Change to the directory /usr/share/zoneinfo, here you will find a list of time zone regions. Choose the most appropriate region, if you live in Canada or the US this directory is the "Americas" directory.
3. If you wish, backup the previous timezone configuration by copying it to a different location. Such as `mv /etc/localtime /etc/localtime-old`.
4. Create a symbolic link from the appropiate timezone to /etc/localtime. Example: `ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime`.
5. If you have the utility rdate, update the current system time by executing `/usr/bin/rdate -s time.nist.gov`.
6. Set the ZONE entry in the file /etc/sysconfig/clock file (e.g. "America/Los_Angeles")
7. Set the hardware clock by executing: `/sbin/hwclock --systohc`
2. Change to the directory /usr/share/zoneinfo, here you will find a list of time zone regions. Choose the most appropriate region, if you live in Canada or the US this directory is the "Americas" directory.
3. If you wish, backup the previous timezone configuration by copying it to a different location. Such as `mv /etc/localtime /etc/localtime-old`.
4. Create a symbolic link from the appropiate timezone to /etc/localtime. Example: `ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime`.
5. If you have the utility rdate, update the current system time by executing `/usr/bin/rdate -s time.nist.gov`.
6. Set the ZONE entry in the file /etc/sysconfig/clock file (e.g. "America/Los_Angeles")
7. Set the hardware clock by executing: `/sbin/hwclock --systohc`
How to resolve permission issues when you move a database between servers that are running SQL Server
MORE INFORMATION
When you move a database from one server that is running SQL Server to another server that is running SQL Server, a mismatch may occur between the security identification numbers (SIDs) of the logins in the master database and the users in the user database. By default, SQL Server 7.0, SQL Server 2000, and SQL Server 2005 provide the sp_change_users_login system stored procedure to map these mismatched users. However, you can only use the sp_change_users_login stored procedure to map standard SQL Server logins and you must perform these mapping for one user at a time. For more information about the sp_change_users_login stored procedure, see the "sp_change_users_login" topic in SQL Server 7.0,SQL Server 2000, and SQL Server 2005 Books Online.
Solution:
Under a specific database name, remove the user. But if there are schemas defined by the user/owner, you cannot delete the user from the security menu (studio). So, you need to change the owner to dbo first. And then you can delete the owner. then recreate the owner/user again. Finally, change back the schema ownership
When you move a database from one server that is running SQL Server to another server that is running SQL Server, a mismatch may occur between the security identification numbers (SIDs) of the logins in the master database and the users in the user database. By default, SQL Server 7.0, SQL Server 2000, and SQL Server 2005 provide the sp_change_users_login system stored procedure to map these mismatched users. However, you can only use the sp_change_users_login stored procedure to map standard SQL Server logins and you must perform these mapping for one user at a time. For more information about the sp_change_users_login stored procedure, see the "sp_change_users_login" topic in SQL Server 7.0,SQL Server 2000, and SQL Server 2005 Books Online.
Solution:
Under a specific database name, remove the user. But if there are schemas defined by the user/owner, you cannot delete the user from the security menu (studio). So, you need to change the owner to dbo first. And then you can delete the owner. then recreate the owner/user again. Finally, change back the schema ownership
Subscribe to:
Posts (Atom)