Some new rows didn't Trigger my Zap
When using the "New Row" Trigger, each poll captures the 50 most recent rows. That means if more than 50 rows are added in a polling interval (depending on your plan), some data will be lost.
If you need to capture more than 50 rows at a time, you'll want to add them to your database in batches according to your plan's update time—no more than 50 records at a time per update period.
Can't Connect To My Database
Database connections can be very fickle. Here are a few things you can re-check:
- What version is your SQL Server database?
Zapier only supports the newest version of SQL Server and even then minor driver problems can cause incompatibilities. Zapier has tested SQL Server integration against Amazon AWS SQL Server 2008 R2 and 2010 RDS instances.
Database connections can be very fickle. Here are a few things you can re-check:
Is your database IP restricted?
This is useful if you use a non-AWS host, for example: Rackspace, HostGator, Linode, DigitalOcean, etc. Zapier connections currently come from static IP addresses. Zapier will make connections to your database from the following IP address:
- 54.86.9.50
Important: Don't forget to do both things: open up your firewall and add the IPs to your user GRANT permissions.
For example, if you wanted to grant SELECT access to a user called zapier on a your_database.your_table in PostgreSQL, you'll need to use the following command:
GRANT SELECT ON your_database.your_table TO 'zapier'@'54.86.9.50' IDENTIFIED BY 'your_password';If you plan to insert, make sure to add the insert statement to the grant:
GRANT SELECT, INSERT ON your_database.your_table TO 'zapier'@'54.86.9.50' IDENTIFIED BY 'your_password';You might try granting all privileges to verify the Zap is working, then narrow down on just the permissions you actually need.
For PostgreSQL, you'll need to configure the server to accept logins from remote IPs (in pg_hba.conf), and create a user for Zapier to use.
Important: If you are hosting your database on Amazon AWS please follow the steps for using Amazon RDS/EC2 below.
Is your database listening on a public interface?
Be sure your database isn't bound to only listening to 127.0.0.1 - commonly you want to bind it to 0.0.0.0 or * or remove that restriction completely. Check your my.conf, postgresql.conf or similar configuration.
Using Amazon RDS/EC2 or Heroku?
You need to make sure we can access the database from 54.86.9.50/32.
Amazon RDS/EC2
If you are using Amazon RDS or EC2 for your database, you need to add 54.86.9.50/32 to your security group.
First, find out if you are on the VPC or Classic Platform.
If you are on the classic platform, navigate to RDS and click "Security Groups" on the left hand navbar. You should see the following:
Select the security group that you are using for your database instance and add the above IP as a CIDR/IP authorization.
Test your connection and if the steps above were completed correctly you should be good to go!
If you are on the VPC platform, please make sure that it is publicly accessible and within a public subnet in addition to allowing the above IP.
See Scenarios for Accessing a DB Instance in a VPC for more details on for both VPC and Classic.
Using Google Cloud Platform (GCP) and CloudSQL?
If hosting MySQL on GCP you need to add the IP (54.86.9.50) to the "Authorised networks" section on the "connections" tab within CloudSQL.
Additional information and instructions here: https://cloud.google.com/sql/docs/mysql/configure-ip#add
Check username, password, SSL certificates
Check for typos, permissions, and spaces at the end of fields and make sure they are all entered correctly.
Is your database very slow?
It isn't uncommon to see queries take much too long for Zapier to correctly operate - you should ensure your queries run well under the 30-second limit we impose. Remember, if you are doing WHERE clauses to add indexes on those columns, please be sure your id column has an index as well (normally that is a primary key and is automatic).
I'm getting errors about DateTime conversions
If you're using a DateTime column type and receiving errors about converting text into DateTimes, you should try using the date type or the datetimeoffset type.
Unknown Connection Timeouts
One known issue that has been reported by a number of our users occurs if you setup SQL Server and install a non-default instance (for example, a named instance). When this is done, the communication port is actually changed but SQL Server uses SQL Server Browser to relay messages to and from port 1433. For one reason or another our integration doesn't work well in this situation. We recommend using the default instance for "the path of least resistance" but if that is not doable you will need to make sure that TCP communication is enabled and you have static port set for the service.
Login failed for user
The error that commonly looks like (ProgrammingError) ('42000', "[42000] [unixODBC][FreeTDS][SQL Server]Login failed for user 'username'. (18456) (SQLDriverConnect)") None None is a commonly a bug with our password connection string encoding - try switching to a long alphanumeric password - we recommend this tool for generating strong passwords.
Garbled or otherwise incorrectly converted data coming from the trigger
As of right now, we only support UTF-8 encoding. You will wish to ensure your DB is set to UTF-8 in order for us to work with the data.
My trigger of New/Updated Row isn't picking up any of my updates
You'll need to specify ORDER BY by a date/time field such as date_updated or last_modified.
