To aid in the porting process, you can probably remove the execute method from porting the command objects (it was a bad idea to link the two ideas). The command objects exist to bridge from JDBC (or a JDBC like API) calls to an object and then the CommandSink does the conversion (via Java Serialization or some other mechanism) and transport to the server and back again. The hard part is if your target server uses Java Serialization (RMI does this, HTTP doesn't) in which case you have to bake your...
Hello Hunter Thanks for your useful suggestions. I might be able to start on my efforts next week and will post my code. I will be using Visual Studio 2017 and will make sure to import the classes you suggested. Regards Gagan On Sat, Jun 9, 2018, 1:22 PM Hunter Payne sfcat@users.sourceforge.net wrote: Well, that's a lot of work. To do that, you probably would first port the de.simplicit.vjdbc.command package to .NET and then the Virtual driver classes (classes with a name like de.simplicit.vjdbc.Virtual*)....
Well, that's a lot of work. To do that, you probably would first port the de.simplicit.vjdbc.command package to .NET and then the Virtual driver classes (classes with a name like de.simplicit.vjdbc.Virtual*). The rest would be porting over classes that those two sets of classes need. The code isn't separated properly into different dependent jars which would enforce separating the client and server classes which always bugged me but wasn't a real problem (it would help here). Make sure you read the...
Thanks for the prompt reply Hunter. Could you please also help in letting me know the steps like which driver to download, any sample code etc. Will there be a different vjdbc driver for connecting to oracle db and different for connecting to sql server or mysql? Regards Gagan On 1:58AM, Sat, Jun 9, 2018 Hunter Payne sfcat@users.sourceforge.net wrote: There is no reason you couldn't write a .NET client side implementation of vJDBC's functionality and it could talk to a server using vJDBC and the...
There is no reason you couldn't write a .NET client side implementation of vJDBC's functionality and it could talk to a server using vJDBC and the existing protocol. So in that case a normal DB using vJDBC could talk to a .NET implementation speaking the same protocol. Otherwise vJDBC is a JVM only implementation (as its 100% Java). Hunter On Friday, June 8, 2018, 8:08:35 PM PDT, Gagan Sharma gagansharma7@users.sourceforge.net wrote: [support-requests:#10] VJDBC driver using .Net Status: open Group:...
VJDBC driver using .Net
I am using TIBCO JasperSoft Studio ,database connection is successfully connected...
This was based on revision 72
Apache HttpClient 4.1, MS SQL Server JDBC driver, database shutdown handling, connection pool work
Apache HttpClient 4.1, MS SQL Server JDBC driver, database shutdown handling