I was trying to migrate from PostgreSQL data from PostgreSQL 9.0.0 to 9.3. I am having an issue related to the collation.
ERROR: could not determine which collation to use for string comparison
Hint: Use the COLLATE clause to set the collation explicitly.
I have done quite a research and found that it has an issue in pre-9.1 we have "citext" and in post-9.1 we have to add the extension. [if I understood correctly].
Here what I have done so far :
Taken the dump from 9.0.0 database.
Installed the instance 9.3.1 in another instance.
Created a database there and run the following query to add the extension CREATE EXTENSION citext. Till here I do not have problem.
While importing the dump from 9.0 after executing the query, I am getting a error, as extension "citext" already exists.
I am not sure if i have done the correct steps in resolving the problem. As per mu understanding, in post 9.1 postgres, we do not have "citext" extension so we manually adding the extension by running the query. So now why it is trying to add the "citext" extension "create citext;" to add citext.
Please correct me if i am leading in a wrong direction.
Thanks
Sovan
Related
We just upgraded our Postgres installation from 9.1.6 to 9.3.9.
We have a nightly process that copies a database from a partner and restores it on our server. There are geometry columns in that database.
I installed PostGIS through StackBuilder and I enabled the extension using
CREATE EXTENSION PostGIS
I verified that it was installed using
SELECT PostGIS_full_version()
But I am getting errors when restoring the table that type 'geometry' does not exist.
Thanks in advance!
Have you tried installing these extensions as well:
CREATE EXTENSION postgis_topology;
CREATE EXTENSION postgis_tiger_geocoder;
I have a database named housing that I want to export. However, everytime i export it, it generates a blank dump file. I cannot identify what I've been doing wrong. Please help.
I'm trying using phppgadmin, I clicked export, selected SQL, structure and data as format and then download, but the dump file generated is always blank.
I think I know now what the problem is, I have different two versions of postgreSQL installed on my laptop. postgreSQL version 9.3.6 that comes with Bitnami WAPPstack) and I forgot that I had previously installed postgreSQL version 9.4.1 too. I get a pg_dump aborting because of server version mismatch. How do I fix this? Can I just simply uninstall the one that is not with the Bitnami WAPPStack? Or will my database be deleted along with it? I'm sorry I know nothing . :(
http://www.expertphp.in/article/postgres-phppgadmin-problem-empty-sql-dump-after-export
https://www.youtube.com/watch?v=L4W_6jnBXk0
Short:
In /usr/share/phppgadmin/dbexport.php.
Change the line from :
$cmd = $exe . " -i";
To
`$cmd = $exe;
and then change
passthru($cmd);
To
echo passthru($cmd);
I'm trying to migrate a SQL Server 2008 R2 database to SQL Azure, I'm using the deploy database to azure wizard and am getting the following error:
Error SQL71564: The element Default: [dbo].[SystemDateDefault] is not
supported when used as part of a data package (.bacpac file)
I'm getting the same error code referencing a number default and a string default as well. I've never tried this migration before and have no clue where to even start with this.
Anyone had this before or have any ideas what I should be doing?
Thanks
Alex
I started by deleting Extended Properties (as my the error message stated, same SQL 71564 id). I used a script found here:
Drop all extended properties on SQL Server
But after many attempts I found it easier to script the entire db, make some adjustments, recreate the db from scripts and finally deploy to Azure.
I've had a bit of a dig around inside SQL and it turns out this is a default value for a user defined type.
I've removed it and things are going fine now.
Thanks anyway.
I am not able to remove sql server 2008 from my machine.
I installed it in the past as a part of the installation of an application, this installed the runtime of sql server 2008 SP0. But now I cannot uninstall.
I tried to use the setup of SP0 and even of SP2 but it was not able to uninstall, by giving fatal errors when it does the preliminary checks.
This means that the only option I have is format my machine?
I cannot even intall a new instance, something is really corrupted.
Is it a way to remove it manually?
I fixed a similar issue by using Microsoft fixit tool
http://support.microsoft.com/mats/Program_Install_and_Uninstall/
I tried to uninstall 3 times and the third time it was succesful, anyway I was not able to install due to fatal errors in the installer.
By trial and error I found that the problem was a list of non existing files in the following registry key (Windows Vista):
HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\PendingFileRenameOperations
So i simply deleted The key PendingFileRenameOperations and tried to install, it installed succesfully.
Anyway thinkinf of automatizing this is crazy, the best way to reinstall is to isntall on a new machine (I mean for customers).
This is part of my job which I've been doing for a few years now. I've probably uninstalled it about 200 / 300 times and find it difficult sometimes.
What errors are you getting?
Have you manually deleted it from
C:\Program Files\Microsoft SQL Server
If you can, do so (or just rename) and then try to add-remove. You most likely won't be able to so the next course of action will be to manually strip it from the registry or use CC Cleaner to strip it out.
Let me know if that doesn't work and i'll offer another suggestion. I believe MS has a tool to force removing programs from the list if the MSI isn't available.
Good Luck it's not the nicest thing to do!
I've long been a fan of Stored Procedure Keyboard Accelerators, as described in this article. When we moved from SQL 2000 to 2005, though, and from Query Analyzer to Management Studio, the handling of the arguments changed. In QA, comma-separated arguments were automatically read as two separate arguments. In SSMS -- at least for me -- it's being read as one argument, with commas in it. Similarly, if I pass in a single argument with single quotes in it, I get a syntax error, unless I escape the quotes (' -> ''). In the article linked above, the author implies that this should not be the case for SSMS, but even with her exact example, comma-separated arguments are still being interpreted as one argument on every SSMS installation I've tried it on (3 of them), running against every SQL Server installation I've tried (4 of them).
E.g., typing the following into SSMS,
Person,4
then selecting it and running the shortcut, I get the error message "Invalid object name 'Person,4'.
Does anybody have any idea how to fix this? Does anybody even use these shortcuts? I've Googled this problem several times over the past two years, and have had no luck.
Edit: May be an issue with a specific build of SSMS. I have a follow-up post below.
I had never tried this until I read your question and then read the article you referenced, so take this with a grain of salt.
That said, I am able to get the process to work on my computer using SSMS, and I am also able to duplicate the error you described.
To get this to work as expected I created the sproc in the master database, assigned the keyboard shortcut and restarted SSMS. I then typed the databasename.schema_name.table_name in single quotes followed by a comma and then an integer value (the sproc I tested was the GetRows sample in the article). I was still connected to the master database.
This worked without incident.
To get the same error that you mentioned, I removed either the reference to the schema name or database name and received the same error you did.
Perhaps you need to add the database name and schema name before the table name?
Tim's suggestion didn't solve my problem on my development PC, but it did convince me to try again from a different PC. When using a different PC's SSMS to log into the development PC's database and trying exactly what Tim describes, I'm having the same behavior Tim describes.
I was also able to re-replicate the argument parsing issue on the other PCs I had tried in the past. I'm hoping Tim can let me know what's the version and build number on his SSMS installation, because my current theory is that the problem is just from the specific build that my coworkers and I have on our dev PCs -- the version string is "Microsoft SQL Server Management Studio 9.00.1399.00". All of our installs of that version took place well over a year ago, so I don't know that I can trace back what disk it's from.
The one that is NOT having the problem is actually our development server, which has "Microsoft SQL Server Management Studio 9.00.3042.00" installed. I don't know if this might be something I can make go away by patching or something, but it currently looks like 1399 reads the entire selection as a single argument, while 3042 does some pre-parsing. I've also recently found that when I pass in a string that contains "--" (comment token) in 3042, everything after the "--" is ignored, while in 1399, it's all included in the first argument.
I am using SSMS version 9.00.3042.00 as well, which probably explains why it is working on my machine.
Agree with Tim. I have just upgraded to SQL Server 05 sp2 and I confirm that this bug gets fixed.