I have a question regarding license for JOOQ being used as a sql builder with AWS RDS being the underlying database.
Can the ASL 2.0 be used or Jooq license is required?
Thanks,
Kanika
Per jOOQ 3.13, there is no separate licensing option for AWS RDS. If you’re planning to use jOOQ with MariaDB, MySQL, or PostgreSQL on AWS RDS, the ASL 2.0 licensed jOOQ Open Source Edition will suffice. If you’re planning to use jOOQ with Aurora, Oracle, or SQL Server on AWS RDS, the jOOQ Professional Edition will be needed.
See the jOOQ database support website for an up-to-date list of supported database products per jOOQ edition and distribution.
Related
[Question posted by a user on YugabyteDB Community Slack]
This is regarding migration from a different source DB to YugabyteDB.
I can see that 'YugabyteDB Voyager' supports Postgres, Aurora, MySQL and Oracle only as source database for Migration to YugabyteDB.
How to migrate SQL Server and DB2 database to Yugabyte?
Appreciate if someone can throw more insight into this topic as I have a use case where we are evaluating YB as the target database and we have SQL Server and DB2 as source.
Both SQLServer and DB2 as a source are on the roadmap for YugabyteDB Voyager, but not been scheduled or prioritized for any release yet.
You can use pgloader for offline migration. For live migration you can try blitzz.io
am looking to compare the aurora DB and RDS DB in aws. I see that aurora can also use RDS behind the scenes.
I have worked in sybase and sql server in the past. For these difference is clear as they are two different products with their own SQL and admin consoles. I couldn't draw similar picture for aws databases.
The main difference is the deployment, escalation and managing tools that AWS (or GCP's Database) offers you. The engine (Aurora in your case) is the component that those services use to CRUD data from the Databases they manage.
Amazon Relational Database Service (RDS)
Google Cloud databases
Hi Is it possible to connect Azure Postgres SQL Database to PowerBI using Direct Query, I cant seem to find information regarding this.
Currently these are the only data sources supported by DirectQuery:
Amazon Redshift
Azure HDInsight Spark (Beta)
Azure SQL Database
Azure SQL Data Warehouse
Google BigQuery (Beta)
IBM DB2 database
IBM Netezza (Beta)
Impala (version 2.x)
Oracle Database (version 12 and above)
SAP Business Warehouse Application Server
SAP Business Warehouse Message Server (Beta)
SAP HANA
Snowflake
Spark (Beta) (version 0.9 and above)
SQL Server
Teradata Database
Vertica (Beta)
PostgreSQL is supported, but only in import mode. So no, you can't use DirectQuery with PostgreSQL (unless you write your own custom connector). You can vote for this idea though.
I'm working on a Custom Connector that will work for Direct Query from PostgreSQL through an ODBC driver. Working on a full write-up (this month when I get time) but until then I can just share the repo here:
DirectQuery for Postgres via ODBC
This is working for us to DirectQuery our Postgres data source via an Azure hosted Windows instance running the custom connector on a On-Premise gateway 24/7.
I want to use Azure table storage with loopbackJS. Is there any library to use this or can any one please help me to how can i use this.
Loopback doesn't have a commercial Azure Table Storage connector available currently, and neither is there a community connector for it.
You can write a new connector yourself, but that may be overkill/difficult for you.
If you're flexible about your Azure NoSQL technology you could look at using Azure DocumentDB which has protocol support for MongoDB, so you could use the Loopback MongoDB connector.
We are investigating moving to a cloud model and the Microsoft Azure PaaS platform.
Our current data layer is written using LINQ to SQL. Will it be compatible with SQL Azure?
Yes LINQ to SQL is compatible. But you have to keep 2 things in mind:
SQL Azure is not a dedicated machine for you alone. Your databases will run on machines with other customers. You may be throttled, you can encounter transient exceptions, ... That's why you should implement a retry policy. There's an article on TechNet explaining how to do this with LINQ to SQL.
Since SQL Azure is not a real SQL Server there are some limitations. Read all about those limitations here: General Guidelines and Limitations (Windows Azure SQL Database). If you're planning to move an existing database (with or without data) to SQL Azure, consider using a tool that supports SQL Azure like the SQL Database Migration Wizard (SQLAzureMW).