I am looking to create a connection with Universe DB using .NET Core Web API and run SELECT queries but I am getting an error and have heard that U2.Data.Client cannot be used for .NET Core. Is there any workaround for this?
Below is the code which I am trying to execute but an exception is thrown while initializing U2Connection:
U2Connection con = new U2Connection();
U2ConnectionStringBuilder csb = new U2ConnectionStringBuilder();
csb.AccessMode = "Native";
csb.RpcServiceType = "uvcs";
csb.Database = "HS.SALES";
csb.UserID = "user";
csb.Password = "password";
csb.Server = "localhost";
csb.ServerType = "universe";
con.ConnectionString = csb.ToString();
con.Open();
These are the exceptions which I get when calling the U2Connection constructor:
System.TypeInitializationException: 'The type initializer for 'U2.Data.Client.U2Connection' threw an exception.'
MissingMethodException: Method not found: 'System.Security.Policy.Evidence System.Reflection.Assembly.get_Evidence()'.
There is no .Net core version of Universe database connector yet! If you are using .Net core 2.x you can target .Net Framework as workaround to be able to use a .Net Framework library where you manage you Universe database access by using the available connector from U2 Toolkit for .NET.
Hope this will help you.
Related
I am writing unit test for testing JPA DAO and I would like to automatically load the javaagant (JPA class enhancer) without having to specify the -javaagent vm parameter.
To achieve this I implemented a #BeforeClass annotated method like this:
String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName();
String pid = nameOfRunningVM.substring(0, nameOfRunningVM.indexOf('#'));
VirtualMachine vm = VirtualMachine.attach(pid);
vm.loadAgent("openjpa-all-2.4.2.jar");
vm.detach();
emf = Persistence.createEntityManagerFactory("TEST_DB");
But I still get the error telling entity classes were not enhanced when creating the entity manager factory.
org.apache.openjpa.persistence.ArgumentException: This configuration disallows runtime optimization, but the following listed types were not enhanced at build time or at class load time with a javaagent: ")
I can live with the -javaagent parameter but I am curious and would be pleased if anybody could share a solution or idea with us.
I am running my test with JUnit and Java 8
I am using the GORM option to store the generated token in database for my Grails 3.x application using grails spring security rest plugin.
The application generates the token but does not get stored in database. Do we need to override the tokenStorage method and have our own implementation to store the token in database
The plugin properties configured in application.groovy are listed below
grails.plugin.springsecurity.rest.token.validation.useBearerToken = false
grails.plugin.springsecurity.rest.login.endpointUrl = '/api/login'
grails.plugin.springsecurity.rest.token.validation.headerName = 'X-Auth-Token'
grails.plugin.springsecurity.rest.token.storage.useJwt = false
grails.plugin.springsecurity.rest.token.storage.useGorm=true
grails.plugin.springsecurity.rest.token.storage.gorm.tokenDomainClassName='com.auth.AuthenticationToken'
grails.plugin.springsecurity.rest.token.storage.gorm.tokenValuePropertyName='token'
grails.plugin.springsecurity.rest.token.storage.gorm.usernamePropertyName='username'
grails.plugin.springsecurity.rest.login.passwordPropertyName = 'password'
grails.plugin.springsecurity.rest.login.useJsonCredentials = true
grails.plugin.springsecurity.rest.login.useRequestParamsCredentials = false
grails.plugin.springsecurity.rest.token.rendering.authoritiesPropertyName = 'permissions'
Make sure you have added the following to your build.gradle:
compile 'org.grails.plugins:spring-security-rest:2.0.0.M2'
compile 'org.grails.plugins:spring-security-rest-gorm:2.0.0.M2'
And you have defined the following in application.groovy or application.yml
grails.plugin.springsecurity.rest.token.storage.useGorm=true
grails.plugin.springsecurity.rest.token.storage.gorm.tokenDomainClassName = 'com.yourdomain.AuthenticationToken'
grails.plugin.springsecurity.rest.token.storage.gorm.tokenValuePropertyName = 'tokenValue'
grails.plugin.springsecurity.rest.token.storage.gorm.usernamePropertyName = 'username'
There is almost no information to help you. No build configuration, no logs, no idea how the requests are made...
But from the description of your problem, my guess is that you are missing the GORM module in your classpath. It's clearly stated in the documentation.
Be also sure to read the what's new in 2.0 chapter.
I had the same problem, token not stored and no error messages seen.
After installing the GORM plugin:
compile "org.grails.plugins:spring-security-rest-gorm:2.0.0.M2"
I could login and a token was saved into the table.
I am writing an application (using .NET Framework 4.5.2 + SQL Server 2014 installed locally). The application needs to support both SQL Server 2014 and previous versions.
When reading data using the inbuilt SQLCLR-types (SqlGeometry, SqlGeography, SqlHierarchyID), the standard ADO.NET methods (e.g. DataReader.GetValues()) use the 10.0.0.0 assembly, and throw an exception due to a mismatch with the loaded (v11 or v12) version.
The reasoning is documented (though it takes a while to spot) in the Breaking Changes in SQL Server 2012 (for the 11.0.0.0 assembly). For SQL Server 2012, there are three workarounds listed:
Use Type System Version=SQL Server 2012 in the SQLConnection.ConnectionString
OR: Use app.config / runtime / assemblyBinding / dependentAssembly to re-map v10.0.0.0 to v11.0.0.0
OR (not a very "neat" way to handle it): rewrite your own code to manually deserialize from a SqlBytes instance...
When developing from a computer with SQL Server 2014 installed, the assembly version is v12.0.0.0, and similar issues arise:
System.InvalidCastException: Unable to cast object of type Microsoft.SqlServer.Types.SqlGeometry to type Microsoft.SqlServer.Types.SqlGeometry.
For SQL Server 2014 (other than the horrible manual deserialize approach), there only seems to be one workaround (not officially documented in the breaking-changes) - it would appear that the v4.5 SqlConnection hasn't yet caught up with the version of SQL Server:
Use app.config / runtime / assemblyBinding / dependentAssembly to re-map v10.0.0.0 to v12.0.0.0
Question: other than re-mapping v10.0.0.0 to v12.0.0.0 in app.config (which seems to work), is there any other (easier) approach that will use the referenced assembly version?
A quick code-example below shows the failure (without the assembly-remapping in place):
private static void DoStuff()
{
SqlGeography geog_val = SqlGeography.STGeomFromText(new SqlChars("POLYGON((-122.358 47.653, -122.348 47.649, -122.348 47.658, -122.358 47.658, -122.358 47.653))"), 4326);
SqlGeometry geom_val = SqlGeometry.Parse("LINESTRING(1 1,2 3,4 8, -6 3)");
prm_geog.Value = DBNull.Value; prm_geom.Value = geom_val; ReadReturnedSpatialColumns(cmd);
prm_geog.Value = geog_val; prm_geom.Value = DBNull.Value; ReadReturnedSpatialColumns(cmd);
}
private static void ReadReturnedSpatialColumns(SqlCommand cmd)
{
using (var dr = cmd.ExecuteReader(CommandBehavior.SingleRow))
{
dr.Read(); var items = new object[2]; dr.GetValues(items);
var geog_test = dr.IsDBNull(0) ? SqlGeography.Null : (SqlGeography)items[0];
var geom_test = dr.IsDBNull(1) ? SqlGeometry.Null : (SqlGeometry)items[1];
}
}
This issue still exists with Framework 4.6.1 and there appears to be no workaround apart from the 3 you've already discovered. So the short answer to your question is no.
However I would question if you really need version 12 of the spatial types, because (as far as I can tell) they don't add anything over the v11 types. If you'd prefer to use the v11 types so you can use the Type System Version=SQL Server 2012 workaround, you can install the Nuget package that incorporates all three versions (10, 11, 12) - it's specifically designed to allow you to deploy to servers where MSSQL may not be installed.
As a bonus, referencing that package directly and using Type System Version=SQL Server 2012 will ensure that your app will always be using the 2012 spatial types, so upgrading to SQL 2016 won't break anything if it decides to return a different version of them (e.g. 13, or 14, or whatever 2016 will use) by default.
I'm using Postgresql 8.4 and my application is trying to connect to the database.
I've registered the driver:
DriverManager.registerDriver(new org.postgresql.Driver());
and then trying the connection:
db = DriverManager.getConnection(database_url);
(btw, my jdbc string is something like: jdbc:postgresql://localhost:5432/myschema?user=myuser&password=mypassword)
I've tried various version of the jdbc driver and getting two type of errors:
with jdbc3:
Exception in thread "main" java.lang.AbstractMethodError: org.postgresql.jdbc3.Jdbc3Connection.getSchema()Ljava/lang/String;
with jdbc4:
java.sql.SQLFeatureNotSupportedException: Il metodo ½org.postgresql.jdbc4.Jdbc4Connection.getSchema()╗ non Þ stato ancora implementato.
that means: method org.postgresql.jdbc4.Jdbc4Connection.getSchema() not implemented yet.
I'm missing something but I don't know what..
------ SOLVED ---------
The problem were not in the connection String or the Driver version, the problem were in the code directly above the getConnection() method:
db = DriverManager.getConnection(database_url);
LOGGER.info("Connected to : " + db.getCatalog() + " - " + db.getSchema());
It seems postgresql driver doesn't have getSchema method, as the java console were often trying to say to me..
The Connection.getSchema() version was added in Java 7 / JDBC 4.1. This means that it is not necessarily available in a JDBC 3 or 4 driver (although if an implementation exists, it will get called).
If you use a JDBC 3 (Java 4/5) driver or a JDBC 4 (Java 6) driver in Java 7 or higher it is entirely possible that you receive a java.lang.AbstractMethodError when calling getSchema if it does not exist in the implementation. Java provides a form of forward compatibility for classes implementing an interface.
If new methods are added to an interface, classes that do not have these methods and were - for example - compiled against an older version of the interface, can still be loaded and used provided the new methods are not called. Missing methods will be stubbed by code that simply throws an AbstractMethodError. On the other hand: if a method getSchema had been implemented and the signature was compatible that method would now be accessible through the interface, even though the method did not exist in the interface at compile time.
In March 2011, the driver was updated so it could be compiled on Java 7 (JDBC 4.1), this happened by stubbing the new JDBC 4.1 methods with an implementation that throws a java.sql.SQLFeatureNotSupportedException, including the implementation of Connection.getSchema. This code is still in the current PostgreSQL JDBC driver version 9.3-1102. Technically a JDBC-compliant driver is not allowed to throw SQLFeatureNotSupportedException unless the API documentation or JDBC specification explicitly allows it (which it doesn't for getSchema).
However the current code on github does provide an implementation since April this year. You might want to consider compiling your own version, or ask on the pgsql-jdbc mailinglist if there are recent snapshots available (the snapshots link on http://jdbc.postgresql.org/ shows rather old versions).
I get the following error message:
Fatal error: Uncaught exception 'Zend_Exception' with message 'File "Zend\Db\Adapter\Mysql.php" does not exist or class "Zend_Db_Adapter_Mysql" was not found in the file' in C:\wamp\www\VPZ\Lib\Zend\Loader.php:88
Stack trace:
#0 C:\wamp\www\VPZ\Lib\Zend\Db.php(247): Zend_Loader::loadClass('Zend_Db_Adapter...')
#1 C:\wamp\www\VPZ\VPZ_Grid\core\vpz_datagrid.class.php(16): Zend_Db::factory('mysql')
#2 C:\wamp\www\vpz_test.php(9): VPZ_DataGrid->ConnectDb(Object(VPZ_Connector))
#3 {main} thrown in C:\wamp\www\VPZ\Lib\Zend\Loader.php on line 88
I dont know what about this and find directory in "Zend\Db\Adapter\Mysql.php" not have but have Mysqli.php
you are trying to create a Zend_Db object with MySQL adapter, I think. there is no MySQL adapter by default for Zend Framework. you should use MySQLi adapter, or Pdo_Mysql.
checkout your code, where you are creating your Zend_Db object. pass in 'Pdo_Mysql' as your adapter name, instead of 'Mysql':
$_db = Zend_Db::factory('Mysql', $configArray );
// uses mysql adapter, which is not available by default.
$_db1 = Zend_Db::factory('Mysqli', $configArray );
// uses mysqli adapter, but needs php_mysqli extension to be installed.
$_db1 = Zend_Db::factory('Pdo_Mysql', $configArray );
// uses PDO mysql adapter which is much better, but needs PDO to be installed, which most of times is installed.
you can write your own adapter for Zend_Db. write a class and extend the Zend_Db_Adapter_Abstract. but there are some problems to implement Mysql adapter, because PHP_MySQL extension (that will provide PHP with mysql_* functions) does not support many features (like client stored procedures, ...). so you can not implement all of methods that other Zend_Db_Adapters have. I've done this before. I wanted to use my application, that used Zend Framework, and I hosted it on a server that PDO and Mysqli were not installed. I implemented a Mysql adapter for Zend_Db, but because I knew which methods are not implemented, I avoided calling those.
the best thing is if you could have PDO installed, and use Pdo_* adapters.