I created a view on a machine using the substring function from Firebird, and it worked. When I copied the database to a different machine, the view was broken. This is the way I used it:
SELECT SUBSTRING(field FROM 5 FOR 15) FROM table;
And this is the output on the machine that does not accept the function:
token unknown: FROM
Both computers have this configuration:
IB Expert version 2.5.0.42 to run the queries and deal with the database.
Firebird version 1.5 as server to database.
BDE Administration version 5.01 installed, with Interbase 4.0 drivers.
Any ideas about why it's behaving differently on these machines?
Make sure Firebird engine is 1.5 and there's no InterBase server running on this same box on the port you expected Firebird 1.5.
Make sure you don't have any UDF called 'substring' registered inside this DB so that Firebird is expecting different parameters.
Different engine versions?
Have you tried naming that expression in the result?
SELECT SUBSTRING(field FROM 5 FOR 15) AS x FROM table;
Related
I have a JDBC connection to a SAP HANA database and I want to query whether it's a SAP HANA Cloud db or not. I know I can find the version with:
SELECT VERSION FROM SYS.M_DATABASE;
and this gives me 4.00.000.00.1608802791 for the cloud and 2.xx for my on-premise Dockerised version, but to avoid hard-coding version numbers everywhere, is there an equivalent query to, say, SQL Server's SELECT SERVERPROPERTY('edition')?
You could use SELECT VALUE FROM M_HOST_INFORMATION WHERE KEY='build_branch'
On premise: fa/hana2sp05
In the cloud: fa/CE2020.36
You might also like M_SYSTEM_OVERVIEW, it has interestign informations such as the server start time.
I try to convert mysql data base to mssql, I used SSMA.
At first I converted schema from mysql to mssql, then I synchronized it.
Finally I migrated data's and faced with these errors:
Column 'column1 for example' does not allow DBnull.vallue
used softwares:
sql server 2016
mysql work bench 6.1
SSMA
In this case, I’d like to suggest you either change the source data to ‘0000-00-01’ works well with ‘Zero-date in NOT NULL Columns’ or set destination column to NULL so you could process null data after the migration is complete.
Lot's of people have asked and been responded to about how to determine the version of the sql server using things like ##VERSION, or SERVERPROPERTY('productversion') but none of these work with sql server compact edition 4.
Is there some universally supported method to determine which sql server edition and version is in use through a sql query or ado.net code that works for compact edition all the way to full sql server?
I want to determine which exact edition / version of SQL server is in use so I know what type of paging query to issue from my code. Sql CE 4 uses a new format for paging queries same as sql server 2011 (denali) and 2005 and 2008 have their own method that is unsupported in CE 4.
I think the answer is that it's impossible but I just want to be sure I didn't overlook something.
I don't really work with SQL Server anymore but here is my attempt at this little problem.
For version 4 of compact edition the following should give you the version and build.
var ver = new System.Data.SqlServerCe.SqlCeConnection().ServerVersion;
And the following should give you the assembly version
var version = typeof(System.Data.SqlServerCe.SqlCeConnection).Assembly.GetName().Version;
Take a look at this blog post. It has a link to download a utility that detects which version of SQL Compact edition you're running. It also has a link to the source code for the utility which may be of interest to you.
You can use PowerShell , in versions of Windows 7 or newer , it comes pre- installed by default. Use the following command lines :
[System.Reflection.Assembly]::LoadFrom("SQLCeAssembly.dll").GetName().Version
Outputs this:
Major Minor Build Revision
----- ----- ----- --------
4 0 0 0
run this
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
See details here
I've developed my website using EF4 and SQL Server 2005, but when moving to the staging site it turns out that they use SQL Server 2000.
Now I'm getting this error, which I believe is related to SQL Server 2000:
Incorrect syntax near '('. 'row_number' is not a recognized function name.
Is there a way of fixing this?
Thanks
EF v4 does not support SQL Server 2000. More details here:
https://connect.microsoft.com/VisualStudio/feedback/details/499186/entity-framework-v2-doesn-t-support-sql-2000
I came across the exact same problem and as per the comments/responses on StackOverflow I had almost given up and flicked it to client to upgrade their database to > 2000 version. Unfortunately that wasn't possible for them due to many other issues. I had to go around googling for a solution and from somewhere I found a work-around.
This is what I did.
Right clicked the ModelName.EDMX file -> Open With
Selected XML (Text) Editor
Found ProviderManifestToken="2005" and replaced it with
ProviderManifestToken="2000"
Published the changes and voila!
Now the reason I'm saying it's a work-around (not a solution) is because
If you update your model from database again and your development
machine database is >= 2000 (which is likely to be a case as SQL
2000 connection is not supported at all by MS according to this
article) this value in the XML will change automatically
Also, the queries generated by EF after this change have worked in
my situation but I cannot guarantee that all the queries ever
generated by your application would work without any problems
Row_Number() returns the sequential number for a each row returned. Are you calling Row_number(), or is the entity framework?
Either way, you may be able to write a user-defined function that re-implements ROW_NUMBER. Stackoverflow post on this here:
ROW_NUMBER Alternative for SQL Server 2000
Not sure this is going to do any good in the long run; you're likely to find that you get around this problem only to encounter the next reason that EF doesn't work on SQL 2000. But, it might be worth the few minutes to try.
I have a value in the database which is 2.700000002. When I run a query in Management studio in SQL SERVER 2005 I get 2.7. But when I run in SQL SERVER 2000 query analyzer it comes 2.700000002.
2.70000002 is correct why is SQL SERVER 2005 trying to change the value by rounding it or selecting the floor value?
Exactly the same target server, database, datatype, processor, architecture etc?
If not, it's simply how the tools will display an approximate float value
Most things round off numbers for display.
~$ ghci
Prelude> 2.7
2.7
~$ irb
>> 2.7
=> 2.7
~$ python
>>> 2.7
2.7000000000000002
For interactive use, this is usually good enough — the only person to see the query analyzer is you, so why does it matter? For actual display, you should specify a format anyway. If you really need the exact value of "2.7", then you should be using a decimal type anyway, as countless articles and answers can tell you.