Has anyone had any luck publishing a VS Database Project over Babelfish? There is nothing on the net related to publishing .dacpac over BabelFish.
I can connect and query via new query in SSMS, however, connection fails while attempting to publish a DB project?
I am assuming there is missing functionality in TDS translation, and this does not fall with Babelfish's "most" tds commands are supported. Also, I am thinking that a Data-tier Application relies on more than just tds translation, there are server-side binaries that are part of the process which may be outside of the babel fish realm.
Would like confirmation from someone who has been down this road though.
Related
I have a graph working fully with the plugin locally in neo4j desktop. I've replicated everything from this graph in my grapheneDB instance. I can't use the gds procedures as I get the error:
gds.proc... is unavailable because it is sandboxed and has dependencies outside of the sandbox. Sandboxing is controlled by the dbms.security.procedures.unrestricted setting. Only unrestrict procedures you can trust with access to database internals.
I know to fix this I need to add these two lines to the config/properties file:
dbms.security.procedures.unrestricted=apoc.*,gds.*
dbms.security.procedures.whitelist=apoc.*,gds.*
I just dont know how to do that on grapheneDB, I've read all the docs I can find.
I've tried adding the gds plugin by adding the jar file as just a stored procedure and then also as a server extension with a zip file containing both the jar file and the two config lines mention above in a neo4j-server.properties file.
When added as a server extension I can tell neo4j hasnt found the gds plugin at all. Am I just missing a location in the properties file? Or am I missing something obvious in the stored procedure upload method?
Using the dev free tier graphenedb, Neo4j Community Edition 3.5.17 and graph data science 1.1.1
Thanks
After a couple of weeks back and forth with graphene support, the config changes have been made. They will be adding support for the GDS plugin as part of their base image soon, but until then you may still need to request that they patch your db for you and add it as a stored procedure.
I have managed to get an XAF application into the Windows Store via the Desktop Bridge.
When a user installs my software from the Windows Store and then chooses to uninstall,
I want them to have the option to completely uninstall the software including the database.
So that they won't have any problem should they later decide to re-install?
Currently, the UWP uninstall does not give an option to delete the database ( or even explain how to delete it ) Thus the user may be tempted to delete the data files via Windows Explorer - which still leaves some instance of LocalDB maintaining an entry in its list of databases.
Thus on a second install after deleting the database files, the UWP program displays the error
"Login failed for user"
As explained in this question
My connection string is using
(localdb)\mssqllocaldb
How do I automate removing the database and memory of it completely?
i.e What uninstall event can I use, What do I override where?
I can't see any executable code in the Desktop Bridge itself.
At the moment I think I may need to put "Run This Before You Uninstall" option in the actual program.
Or perhaps as a workaround, I should code a Clean Up handler for the "Login failed for user" error.
This issue is related
I am using Entity Framework 6.2 and .Net Framework 4.7.2
The Bridge Project is using Windows 10, version 1809, Build 17763 ( Min and Target)
See Getting Started with EF Core on Universal Windows Platform (UWP) with a New Database. It introduces use of migrations. Migrations are designed to help you change your database design and implement the changes in production. Migrations can be frustrating though because Microsoft has not documented the feature thoroughly. There is a list somewhere of the migration features not supported for SQLite; it is important to know about that from the beginning.
I'm pretty new to Informix and I'm trying to run a screen with sperform, but it's just seg faulting when I try to query. So far I have:
installed Ubuntu server 12 (64bit)
installed the Dev suite and runtime 7.50
installed the Informix engine 12.10
verified it was all up and running; can connect with dbaccess
created an example database & table and inserted a couple rows
generated a form using isql from the table
ran the generated form with sperform
As soon as I attempt to query with the form, I get a "Segmentation fault (core dumped)" and it exits. Can anyone help me understand why? Isn't this as basic as it gets?
Preliminary answer
Yes; that is as basic as it gets. No; it should not crash. There are essentially no circumstances under which that sequence should crash. You should probably file a bug report with IBM.
The only thing that might conceivably be an issue is that ISQL may have been built with an older version of the CSDK than the server installs and there may be an unexpected incompatibility. It should work, but occasionally flaws creep in. If you want to explore how to prove this possibility, say so. It is a little fiddly, but may get you up and running while the problem is resolved formally.
Extended answer
YES! I'd love to try to fix this.
The first step, it seems to me, is to see whether ISQL (Informix SQL) runs correctly when installed on its own — rather than when mixed with the Informix server code. It should work in both environments, but it is possible that the new server code has changed something that is causing the older tools code to break.
So, reinstall Informix SQL (and the other dev tools if you want, but you could save those until you've got a POC with just ISQL) into a new directory. Let's suppose your server is installed in /opt/informix; you could install your tools in /opt/isql instead. (No need to uninstall the tools from under /opt/informix yet.)
Copy the server sqlhosts file (from /opt/informix/etc/sqlhosts) to the new /opt/isql/etc/sqlhosts.
Change INFORMIXDIR=/opt/isql.
Add the new value to the front of your path (PATH=$INFORMIXDIR/bin:$PATH).
Worry about the setting of LD_LIBRARY_PATH — you want to pick up libraries from under /opt/isql/lib in preference to those under /opt/informix/lib.
Leave INFORMIXSERVER unchanged; you'll still be talking to the same database server.
You should now try to (re)generate the form file and run it. With a small modicum of luck, it will work now.
OK, that works! Don't know if that's a good thing or not, but we're going to try to get that change into production.
It gets you going; that's good. It's also a relief to me that the fundamentals of the QA process for the tools release didn't break down. The product works when run in the environment it was developed for.
It's a nuisance that a later release of the server changed something so that the older build of the tools no longer works with the newer server. It is supposed to be OK. However, running with separate INFORMIXDIR values for tools and server is not unheard of. If the server was on a separate machine, the segregation would be inevitable — the tools would use a separate INFORMIXDIR from the one used by the server (ignoring NFS file systems, etc)
Is it possible that there's some aspect to my steps that cause something to be overwritten?
No. The classic 'Rule of TEN (Tools, Engine, Network)' — install tools before the server (before the network-enabled version of the server) more or less applies and is what you did. The separate network-enabled version of the server ceased to be relevant about 20 years ago, but tools before engine (the 'Rule of TE' just doesn't cut it) is normally correct.
Since the workaround works, we need to look ahead a bit: what does it mean for you?
You have a solution that will work pro tem.
You will need to be careful with environment setting when you run programs.
Programs using the tools (Informix 4GL, Informix SQL) will be run with INFORMIXDIR=/opt/isql and consequential environment settings.
Programs installed by the server (DB-Export, DB-Import, ON-Stat, etc) will be run with INFORMIXDIR=/opt/informix and consequential environment settings.
If you wish, you can set up scripts in /opt/isql/bin for the programs from /opt/informix/bin that you want developers or users to use.
The scripts in /opt/isql/bin will set the environment correctly for the server and then exec the server program.
The scripts in /opt/informix/bin will similarly set the environment correctly for the tools and then exec the tools program.
In each directory, assuming you're careful, you have a single script that actually sets the environment and runs the other program; the program names are simply (symbolic?) links to the master script.
You have two separate master scripts — one to set the server environment, one to set the tools environment.
You should report the problem to IBM (Informix) Technical Support. You can outline what you've had to do to work around the problem. The fact that you have a workaround will lower the urgency, but it is still a problem that should, ideally, be fixed. (The world isn't ideal though, just in case you hadn't noticed; it may take time for the fix to be delivered.)
Suppose I have Rails 4 app, call it "Super SaaS". Now my client says he likes my appvery much, but he doesn't want his data to be in the cloud. So he says he would buy a licience from me to deploy "Super SaaS" on his own server. More like Atlassian Jira.
The question is: is there any secure way(in terms of protecting source code) to do that?
While you can probably package up your code as a JRuby application with JAR files and Java byte code, there are decompilers for that, so you can never presume your source to be 100% secure.
Ideally you'd offer some sort of VM appliance that the customer can install, a system image compatible with VMWare or whatever virtualization system they're using. This helps package up a fairly secure environment, but won't protect against a determined adversary trying to get your source code.
If you're giving out your code to someone in any form, compiled or otherwise, you have to have a certain amount of trust. Even compiled executables are not immune to reverse-engineering.
I have a friend who has a management application, and he would like to import some of his data in Excel.
The thing is I have no idea about how to read this type of files,
In his application directory he has a folder named app.dbs. Inside there are *.idx and *.dat files.
What would be the easiest way to read this files? Maybe ODBC connector, or installing some version of Informix DB??
That sounds like C-ISAM files, or an Informix-SE (Standard Engine) install. You most certainly can't read them directly. Googling Informix C-ISAM files ODBC generates plenty of results. Also this page explains the relationship between the two.
I've never used SE, but assuming its installation is reasonably similar to its big brother Informix Dynamic Server (and I believe it is), have a look on your friend's computer for an 'Informix' directory. You may find an %INFORMIXDIR% environment variable to point you in the right direction. Within that, look for an executable in its subdirectory bin called dbaccess.exe. Run that from a DOS prompt and you should hopefully get an SQL interpreter that allows you to read and extract the data.
If you have no luck finding such a directory, then it's more than likely the "management application" is writing C-ISAM directly, and you'll need an ODBC driver for C-ISAM, as you surmised.
The name app.dbs containing the .dat and .idx files is an almost sure indication that you have an Informix SE (Standard Engine) database (someone might have faked it, but it is pretty improbable).
Given that you may be able to use an Informix ODBC driver and SE itself to access the database, or you may be able to use an ISAM-based ODBC driver to access the database. It depends in part on whether this is a one-time migration or an ongoing access while the application continues to work on the database.
Assuming all of this is installed on Windows, you should indeed find a %INFORMIXDIR% directory, which will have a dbaccess.exe in the bin sub-directory, and an sqlexec.exe either in the bin directory or in the lib directory (it would be in $INFORMIXDIR/lib on Unix; I'm not sure about Windows). These should be able to access the database. If you find sqlexec but not dbaccess, then you've got a seriously old version (more than 20 years old, but I know of other people still using such archaic versions). You should be able to identify the version by running dbaccess -V or sqlexec -V. If it is 7.25, it is reasonably recent (that's been current for a decade or more); if it is older than that, it is verging on the archaic.