Skip to main content

I am unable to successfully test a connection to a Microsoft SQL Database on the Azure platform.  The Skuid IPs have been added to the firewall, however all it returns in an error.  I am trying to  build out a proof of concept with the trial element, but this will be a non-started is I need to build an OData API service on top of the Azure space. 


We have successfully connected remotely with the Sql Server Data Tools, however there are not other fields to allow me to complete separately.


Any assistance is appreciated.


Just to double-check — is your “URL / Endpoint” in the format of “host:port”, e.g. “my-server-address:port-number” ?


I LOVE AZURE and Microsoft SQL. 

I have made this same connection before and have run into the same thing. 

I made a few screenshots to help me remember what I did when the connection went smoothly. 




Use the server and server admin login info for the fields in New Data Source Step 2.

Note… I usually get stuck here with an error when clicking "Test Connection" here.

So... go ahead and click save, without testing here.  

At this point, the test connection button will result in an error at this point because SSL has not been select.  That is something that can be set in the next step. 



See the screenshot below: Now... Check “Use SSL to Connect.

Then Save

Then Test


Note the syntax around the URL/Endpoint...   databaseservername.dtabase.windows.net:1433

Leaving off the colon and the port has tripped me up before as well. 




Thanks!  Worked perfectly.  Just needed the port!


Awesome!  Here are a couple of lessons learned or things to look out for now that you have made the connection:


(1) When you go to import your table/objects, I have found that it works best without errors to add 2 or 3 at a time instead of adding in groups of 10 or 20.   


(2) If you’re used to working with data sources that have a rich set of metadata, you may need to prepare for some “extra” setup work. 


a) For example, after getting your table/objects imported, you have So many choices to customize… from what is revealed to the page/app builder end users in (conditions) and (access control) to what the fields should be expected to do.  


   


b) Pay special attention to setting up your most important table fields. 



I recall a few times when (in a panic) I asked, “WHY CAN’T I group on FieldX in my Aggregate MODEL?!”  Only to realize that I didn’t remember to mark that field as group-able in the DS setup.  


Reply