Comments (24)
Any ADO.NET provider and consuming code that doesn't call into native code unsupported on PASE should work. Note that if code depends on a native library that is supported, but doesn't load the library, then the DllMap may need to be adjusted. I think Mono comes with an MS SQL, Oracle, Unix DB2, and SQLite provider out of the box.
As mentioned in the README, the IBM-supplied DB2/400 provider won't work due to requiring an ODBC provider only available as a Win32 DLL. Working on cross-platform (including from i) ways to access DB2/400 in .NET is an eventual goal of the project, however.
from binarydist.
Got it. I'll do a little test to see if I can get SQL Server driver to work.
from binarydist.
What level of .Net is supported ? I might be able to tweak my XMLSERVICE wrapper code to work since that uses HTTP.
from binarydist.
The MS SQL driver changed quite a bit in newer Mono; if authentication doesn't work, let us know, as we may have to integrate Kerberos stuff inside. (I'll ask upstream to clarify the situation further, if needed.)
The latest .NET Framework should be supported; there's no need to use Core binaries.
from binarydist.
Tried to use the System.Data namespace.
Should that be part of the base Mono build or is there something I need to include on the mcs command line ?
I simply added the following line to the hello.cs program:
System.Data.Datatable dt = new SYstem.Data.DataTable();
Got following compile error: CS0234: The type or namespace Data does not exist in the namespace System. Are you missing 'System.Data' namespace reference ?
My first time using command line compile with Mono :-)
from binarydist.
-r:System.Data
should do it. Alternatively, you can compile software from another system (including compiled with Visual Studio) and it should work.
from binarydist.
Yep. If I get SQL Server connection working I'll do a little speed test.
from binarydist.
Very simple DB console app attached.
Throw following error when called from PASE on IBMi:
Error:Snix_Connect (provider: SNI_PN7, error: 25 - SNI_ERROR_25)
Snix_Connect (provider: SNI_PN7, error: 25 - SNI_ERROR_25)
Used old style SQL Server connection string syntax.
I'll play some more, but it appears that something with DB access isn't quite right yet.
from binarydist.
We'll try to get a test environment set up; I myself am not familar with MS SQL, so it might take some poking once it happens. Some quick ideas:
-
The server looks like SQL Server Express based on the name - is this licensed or configured to listen on the network?
-
The connection string looks right to us. Might be worth reviewing anyways.
-
You're using the "sa" user, which may be treated special.
-
Could be a bug in Mono?
from binarydist.
Yep the sql server is fine and talking to the network.
I'm betting on a bug in mono.
Stack trace in .net gave no detail.
Let me know if there's a secret to tracing these comms in Mono.
from binarydist.
Yeah, I'm personally inclined to think it might be a Mono bug as well. Do you happen to know which version of SQL Server Express it was, just so we can replicate your test case?
from binarydist.
I do know that Mono has changed over to the CoreFX implementation of the MS SQL client, which IIRC, requires GSS libraries we don't include/use with the build. I'll have to look into seeing if those work, and what can be done to package them.
from binarydist.
That would make a lot of sense, now that I think of it. Looking at the error, I can't help but think "SNI" in the output might be a reference to TLS Server Name Indication.
I did a bit of digging, this seems like it might be relevant: https://forum.unity.com/threads/unity-2018-using-entity-framework.512675/
(It's for the Unity game engine, but I know that uses Mono underneath the covers)
After that i think errors you linked started popping up only because Mono System.Data.SqlClient can't parse all of the connection string formats so i replaced my connection string i usually use in EF Core with a simpler older format: Data Source={SQL_INSTANCE_NAME};user id={SQL_USERNAME};password={SQL_PASS};Initial Catalog={DB:NAME};
@NattyNarwhal I'm going to install the latest MSSQL Express on a box on the same network as our build host tonight and see if I can get it working.
from binarydist.
@glrodgers I am using 2014 Express. Make sure to enable TCP when you configure the SQL Server since that's not enabled by default.
from binarydist.
Hey guys just checking in for status on this ? Now that you're getting some press the first thing people will be looking for is some level of database access. I'll test my XMLSERVICE wrapper for IBMi in the next week or so, but SQL Server and other DB types would be useful as well.
from binarydist.
Real life gets in the way, but a libdb400-based connector for fast local access got bumped up on my priority list. XMLSERVICE is all managed code, so it should work in the interim.
from binarydist.
Just wanted to let you guys know I tested my IBM i XMLSERVICE wrapper and it seems to work fine with no special changes. Was able to run a remote command on the IBM i and query the database to a JSON file successfully and it was quick. I just created a couple of small console apps and run them against my pre-compiled DLL and it worked perfectly. Nice work so far. Db access to other platforms still needed but for me this should cover the immediate IBM i data access needs since PHP and Node rely on the same components for data access.
from binarydist.
Having XMLSERVICE working is good to hear. I had just started work on a from-scratch object-oriented libdb400 wrapper, but I still have the nagging thought in my mind to just refactor an LUW binding and get it up and running faster.
from binarydist.
I might sound a little ignorant, but can you tell me what an LUW is ? :-)
On another note I took some time to refactor one of my other PASE wrappers to create a CL command called MONO which front ends the mono environment setup and program calls for classic IBM i developers to use from a CL or RPG program. The command runs the .Net app, pipelines the console output/stdout back into the IFS, physical file, IBM i primary job log or a spool file so that it can be consumed from a traditional/classic IBM i RPG or CL program. It also catches any failures on the call to Mono. I ended up calling the PASE program via QSHELL because QP2SHELL doesn't deal well with calling a multi-threaded env directly. Apparently in V7R3 (not sure about earlier yet) you can call PASE via QSHELL and QSHELL has always had some functionality to be called as multi-threaded from a traditional IBM i job. Hope that made sense.
I'll post the IBM i wrapper code on a repo soon. It will work out of the box with the environment you've set up.
One last note. How production ready do you think the mono code is currently ? (sans more expansive database support of course) Seemed stable from my initial tests, but needs more exercising.
Thanks again for your hard work on porting the mono code to IBM i. Not many would take that technical challenge on :-)
from binarydist.
LUW = DB2 on Linux/Unix/Windows. The SQLI/CLI API is 99% similar between LUW and i, hence why DB2 Connect works (it basically adapts DB2 on i to speak the DB2 LUW network protocol, AFAIK) if you have that installed. I tried pointing modified LUW clients at libdb400, but it's not 100%; it'll need modification, and might be easier than writing bindings from scratch. (SQL is a little outside my comfort zone, so I'm approaching the from-scratch bindings carefully.)
Green screen and particularily ILE integration is definitely something I want to look at.
Mono works, but it's definitely pre-release quality, and your call on how stable it is. The PPC JIT is a free-time passion thing from the guy who maintains it upstream, there may be AIX API/ABI quirks lurking I haven't squashed, sorting out ASP.NET, and deal with the some of the depency chains; but it's surprisingly stable for what it is. CI runs constantly and is able to pass a majority of the tests.
from binarydist.
I was able to get the older TDS style SQL Server connections to work against SQL Server 2014 from the Mono.Data.Tds.dll library. System.Data.SqlClient still not working right, but was able to use the Mono.Data.Tds.Protocol.Tds80 object to connect and query data from a SQL Server 2014 database. Super speedy.
from binarydist.
Nice. I suspect the JIT is surprisingly speedy despite the fact it doesn't apply optimizations beyond POWER5; there's some stuff about an IR form and optimizing that I don't know the specifics of. I've been meaning to try some benchmarks against J9.
Fixing up System.Data's MS SQL driver is on my TODO list, but good to know there's a workaround replacement library. As I got the notification for this though, I actually just got a hacked up DB2 LUW library to work against libdb400 for a super simple test case - more advanced ones shouldn't be too bad.
from binarydist.
Nice. Once you get it to working order with a sample I'm happy to test it out. I'll plan to do some tests with the SQLite, MySQL and Postgres drivers after vaca.
from binarydist.
SQLite I think I tested to be working; you might just need to adjust the DllMap entries.
from binarydist.
Related Issues (20)
- mkbundle is broken
- AIX takes a long time to start child processes HOT 1
- MemoryMappedFile segfaults
- RuntimeInformation could be better HOT 2
- Mono objects take a while to build
- PPC32 support HOT 3
- Some System.Decimal operations deliver garbage HOT 1
- TimeZoneInfo doesn't work HOT 3
- Fix network interface enumeration on Mono HOT 6
- Take advantage of Mono crash reporting HOT 1
- Dependent module libmonosgen-2.0.a could not be loaded HOT 11
- Benchmark Mono against J9 and other runtimes
- Mono profiler is broken HOT 1
- svr4 style sonames HOT 17
- investigate deadlocks in System and corlib tests
- File.Exists causes app to fail when file not found and used in a Class. HOT 1
- managed rijndael is broken in big endian HOT 1
- DateTime.Now started failing at 1am on Daylight Savings Time 3/10/2019 HOT 4
- Spreadsheetlight causes error with System.IO.Packaging HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from binarydist.