This sounds like the fields for some reason don't have a fingerprint (what we call some precomputed statistics like min & max) on them. If you check your logs do you have any errors during the sync process? You might also want to try manually re-triggering sync from the Admin panel.

Thanks for your help @sbelak .
I run the global database schema SYNC again and don't see any error in log :
[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:03+02:00 DEBUG metabase.middleware.log GET /api/user/current 200 4.6 ms (3 DB calls) App DB connections: 1/15 Jetty threads: 4/50 (3 idle, 0 queued) (128 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:03+02:00 DEBUG metabase.middleware.log GET /api/session/properties 200 6.5 ms (2 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (3 idle, 0 queued) (129 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:03+02:00 DEBUG metabase.middleware.log GET /api/database 200 9.8 ms (3 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (129 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:03+02:00 DEBUG metabase.middleware.log GET /api/session/properties 200 6.3 ms (2 DB calls) App DB connections: 1/15 Jetty threads: 4/50 (3 idle, 0 queued) (129 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:03+02:00 DEBUG metabase.middleware.log GET /api/setting 200 439.1 µs (0 DB calls) App DB connections: 0/15 Jetty threads: 4/50 (3 idle, 0 queued) (129 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:03+02:00 DEBUG metabase.middleware.log GET /api/setup/admin_checklist 200 17.5 ms (11 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:06+02:00 DEBUG metabase.middleware.log GET /api/util/bug_report_details 200 4.7 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 DEBUG metabase.middleware.log POST /api/database/111/sync_schema 200 2.3 ms (1 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.util STARTING: Sync metadata for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.util STARTING: step 'sync-timezone' for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.util FINISHED: step 'sync-timezone' for postgres Database 111 'IZI Report' (12.4 ms) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.util STARTING: step 'sync-tables' for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.util FINISHED: step 'sync-tables' for postgres Database 111 'IZI Report' (59.0 ms) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.util STARTING: step 'sync-fields' for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:39+02:00 INFO metabase.sync.sync-metadata.tables Updating description for tables: (Table 'reporting.appels') [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:46+02:00 DEBUG metabase.middleware.log GET /api/user/current 200 4.3 ms (3 DB calls) App DB connections: 1/15 Jetty threads: 4/50 (3 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:46+02:00 DEBUG metabase.middleware.log GET /api/session/properties 200 6.1 ms (2 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (3 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:21:46+02:00 DEBUG metabase.middleware.log GET /api/database 200 9.5 ms (3 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:00+02:00 INFO metabase.sync.util FINISHED: step 'sync-fields' for postgres Database 111 'IZI Report' (21.0 s) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:00+02:00 INFO metabase.sync.util STARTING: step 'sync-fks' for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util FINISHED: step 'sync-fks' for postgres Database 111 'IZI Report' (6.1 s) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util STARTING: step 'sync-metabase-metadata' for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util FINISHED: step 'sync-metabase-metadata' for postgres Database 111 'IZI Report' (43.5 ms) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util FINISHED: Sync metadata for postgres Database 111 'IZI Report' (27.2 s) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util STARTING: Analyze data for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util STARTING: step 'fingerprint-fields' for postgres Database 111 'IZI Report' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:07+02:00 INFO metabase.sync.analyze fingerprint-fields Analyzed [*****·············································] 😢 10% Table 2,636 'dataprep.report_card_prepared' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:08+02:00 INFO metabase.sync.analyze fingerprint-fields Analyzed [**********········································] 😞 20% Table 2,685 'dataprep.bundle_test' [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:08+02:00 ERROR metabase.sync.util Error running sync step [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:08+02:00 INFO metabase.sync.util FINISHED: Analyze data for postgres Database 111 'IZI Report' (1.7 s) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:24+02:00 DEBUG metabase.middleware.log GET /api/user/current 200 4.6 ms (3 DB calls) App DB connections: 0/15 Jetty threads: 4/50 (3 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:24+02:00 DEBUG metabase.middleware.log GET /api/session/properties 200 6.1 ms (2 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (3 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:24+02:00 DEBUG metabase.middleware.log GET /api/database 200 9.4 ms (3 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:23:31+02:00 DEBUG metabase.middleware.log GET /api/user/current 200 4.5 ms (3 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (4 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:23:31+02:00 DEBUG metabase.middleware.log GET /api/session/properties 200 5.9 ms (2 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (3 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued) [0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:23:31+02:00 DEBUG metabase.middleware.log GET /api/database 200 9.9 ms (3 DB calls) App DB connections: 0/15 Jetty threads: 3/50 (3 idle, 0 queued) (131 total active threads) Queries in flight: 0 (0 queued)

Logs MB.docx
More readable in .doc file maybe

And I have check the Metabase db, you're right there are no fingerprint on these fields but I don't know why...

I don't know which database or table, you're showing in the screenshot, but the log shows an error:

[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util STARTING: Analyze data for postgres Database 111 'IZI Report'
[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:06+02:00 INFO metabase.sync.util STARTING: step 'fingerprint-fields' for postgres Database 111 'IZI Report'
[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:07+02:00 INFO metabase.sync.analyze fingerprint-fields Analyzed [*****·············································] 😢 10% Table 2,636 'dataprep.report_card_prepared'
[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:08+02:00 INFO metabase.sync.analyze fingerprint-fields Analyzed [**********········································] 😞 20% Table 2,685 'dataprep.bundle_test'
[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:08+02:00 ERROR metabase.sync.util Error running sync step
[0da90087-51e3-438e-acae-261909ced75d] 2020-04-16T22:22:08+02:00 INFO metabase.sync.util FINISHED: Analyze data for postgres Database 111 'IZI Report' (1.7 s)

Yes my problem is on database 111, table 2733. But when I check metabase_field I found a lot of other field without any fingerprint on this database.

Is there any action I can run to force MB to build these "fingerprints" ? I have no idea of the root cause, I don't see any pattern on the different number field without fingerprint : some are recently created but others not, some are float but others integer...

Hello again,
I have tried some test and I can confirm that the bug origin is a fail systematic during this "fingerprint analyze".

[ce8bb1c7-9f03-4561-b894-0fb1d6c4d034] 2020-04-18T11:15:06+02:00 INFO metabase.sync.util STARTING: step 'fingerprint-fields' for postgres Database 111 'IZI Report'
[ce8bb1c7-9f03-4561-b894-0fb1d6c4d034] 2020-04-18T11:15:06+02:00 INFO metabase.sync.analyze fingerprint-fields Analyzed [*****·············································] 😢 10% Table 2,623 'raw.diabolocom_variables_recents_cumul'
[ce8bb1c7-9f03-4561-b894-0fb1d6c4d034] 2020-04-18T11:15:07+02:00 INFO metabase.sync.analyze fingerprint-fields Analyzed [**********········································] 😞 20% Table 2,391 'dataprep.diab_appels_by_1er_dern_agent'
[ce8bb1c7-9f03-4561-b894-0fb1d6c4d034] 2020-04-18T11:15:08+02:00 ERROR metabase.sync.util Error running sync step

Is there something I can do to try to solve this fail ? Or a way to "drill down" in this task and identify if it always fail on a specific table/field ?

Thanks

Try launching Metabase with more logging. This enables TRACE for log4j.logger.metabase.sync:

java -Dlog4j.configuration=https://gist.github.com/flamber/53823764c9989415b76acdb9ed88bcc1/raw/e1cd731924c4ae6091a495feec54ab38f5a1543a/log4j-debug-sync.properties -jar metabase.jar

Hello, we use AWS Elastic Beanstalk, so how to apply this configuration to use this please ?

@skyline42sh You would have to change the configuration and upload that. Have a look at this forum comment (might want to read the entire topic):
https://discourse.metabase.com/t/best-practice-for-having-rds-as-part-of-eb-environment/6756/10?u=flamber (EDIT: Seems like some new options are now available if you read some of the later comments)
And please open a new forum topic, if you're still having problems, so this issue doesn't turn into a troubleshooting thread.

@flamber I work with Nico-P-FR that's why I post this question...
I'm gonna check what you send.
Thanks.

@flamber The post in comment doesn't correspond to our case, how to add on the 01_metabase.config the command java -Dlog4j please ?
Thanks.

@skyline42sh
I don't know, seems like working with EBS is uphill. Try EC2, so you have console access. Or do it locally with a JAR/Docker, you should see the same sync problems with the same database.

Okey, I found the solution.
For execute this command on AWS Elastic Beanstalk, add on Configuration, Software, Environment properties the line : JAVA_OPTS = the line on comment.
@Nico-P-FR send you the good logs after analysing.

@flamber With advanced logs I guess I have identified the problem root. It seems to fail and stop fingerprint scan due to some fields name with specific characters like question mark "?".

[914279c4-85cb-4664-8493-f877dcee046f] 2020-05-14T18:12:48+02:00 ERROR metabase.sync.util Error generating fingerprint for Field 'autoliquidation ?'

[914279c4-85cb-4664-8493-f877dcee046f] 2020-05-14T18:12:48+02:00 ERROR metabase.sync.util Error generating fingerprint for Field 'Auto-entrepreneur ?'

I'm tryin to substitute them all to check if it's works without but not easy because we have a lot. I will confirm you if it's totally solve the problem. Thanks

Someone in the forum had similar problem, but with percentage sign % in column names:
https://discourse.metabase.com/t/conversion-v-error/10180/4?u=flamber
Guess the sync+scan code doesn't handle special characters in columns (and perhaps tables too?)

I cannot reproduce on 0.35.4 with Postgres 12.2 with columns that include question mark symbol like Column?

Hello @flamber , we still have problems with fingerprint analyse but we didn't succeed to define a clear pattern. Some field with specific character like "?" or french "é" seems to fail but others are analysed without problem so I am not sure the root cause is around that. We also have error message on very "standard" database not customized at all like our gitlab internal db, and even on very simple table.

For example :
[62fdf17f-ec1b-4af6-8e5c-69ee35d380d2] 2020-06-29T23:04:09+02:00 ERROR metabase.sync.util Error fingerprinting Table 2,579 'public.user_details'

In our case after a lot of investigations we have give up on this problem and try to find a workaround to not use fingerprint because we didn't find any solution.

Could you by any chance share the values in one of the columns that fails (doesn't matter which). I'm thinking it's something in the data that trips fingerprinting up.

I don't think so. For example on this table :

We have an error message during the db sync :
"[62fdf17f-ec1b-4af6-8e5c-69ee35d380d2] 2020-06-29T23:38:56+02:00 ERROR metabase.sync.util Error fingerprinting Table 1,685 'dataprep.ga_pageviews_uniquepageviews_page_channelgroup_device_prepared'"

And this field has only one value on all lines ="Inconnu" as you can see here (from Dataiku) :

I'm not sure there is a link but on this particular table I found another error message when I tried to check the table in Metabase : "ERROR: column ga_pageviews_uniquepageviews_page_channelgroup_device_prepared.landingcontentgroup2 does not exist Hint: Perhaps you meant to reference the column "ga_pageviews_uniquepageviews_page_channelgroup_device_prepared.landingContentGroup2". Position: 449"

The capital letters seems not managed correctly in the automatic SQL query to see the table :

SELECT "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."channelGrouping" AS "channelGrouping", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."date" AS "date", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."deviceCategory" AS "deviceCategory", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."landingcontentgroup2" AS "landingcontentgroup2", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."pagePath" AS "pagePath", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."pagePath_path" AS "pagePath_path", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."pageviews" AS "pageviews", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."uniquePageviews" AS "uniquePageviews", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."week" AS "week", "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"."year" AS "year"
FROM "dataprep"."ga_pageviews_uniquepageviews_page_channelgroup_device_prepared"
LIMIT 1048576

But I guess it is more a consequence of the first problem (the failed analyse) if it's linked than the root cause.

Actually it might be the other way around. Not entirely sure why the name is wrong. Could you manually fix one of the names in the metabase app DB and see if it then syncs that field fine (both for one of the all lower case names and one with an é -- you don't need to fix all of them, just one of each will to, to narrow down the possibilities).

To recap: you get this error on various field types (initial ones were numbers, while landingcontentgroup2 is text.

Also on what version of MB are you on, and do you happen to know the first version you used (if you retained the db throughout migrations)?

Not sure if I have a way to do what you ask me because I don't have direct access to MB database instance. I can just read it through Metabase itself.

For the recap : We have hundreds of fields without fingerprint currently when I check in MB db but the problem for answering your question is that when the fingerprint analysis failed on a field, it seems to stop. So I can't be 100% sure which fields lead the failure and which are just not analysed because the process stopped before.
Some weeks ago I was thinking it was linked to non aZ characters because we have errors on fields with this pattern but as you can see on my last example it is not always the case.
When it works properly, is it normal to have some fields without fingerprint (like on this screenshot) or all the fields without exception should have one after a scan ?

For MB version : we are always up to date (so 35.4 now but a previous one when I post at the beginning of this thread).

All fields should have a fingerprint, at least the generic part (what's called global).

What you are experiencing is really strange, so I really want to get to the bottom of it. We've hardened fingerprinting considerably in the last few release so one fingerprinter going down shouldn’t bring down the rest. Does any field in the table 1730 have a fingerprint?

One more experiment if you don't mind: can you add again one of the databases on which you get the error (just use a different name in MB) and see if the error persists after a fresh add & sync.

No, on table 1730 all the (119) fields has not fingerprints. But we also have fingerprint missing on various other tables (but not on all fields) :

I duplicated the connection and MB is currently creating all the fingerprint. It's long because it's a large DB. I let it work but I need to stop for today. I willet you know tomorrow (from Paris point of view ^^) the result. FYI this particular database is a datawarehouse so I can also do anything on the DB to make some tests like drop temporary the table 1730 for example.

With a new connection on the same db, I don't get the same result (DB 113 is a duplicate of 111) :

@Nico-P-FR Can you post "Diagnostic Info" from Admin > Troubleshooting?
I was debugging an issue, where the warehouse (Panoply using Google Sheets) returned a value N/A one time for a float column, which somehow messed up the fingerprinting, so binning wasn't available: https://discourse.metabase.com/t/latitude-and-longitude-fields-wont-autobin/9806 - and that's likely what most people in #7782 have encountered too.

If the newly connected DB has all the fields and all the fields have a fingerprint, I suspect the state in the MB database got subtly corrupted and/or out of sync with the DB at some point. Did you do any changes to the dbwh schema since connecting it to MB? Perhaps renamed a table or some such? In general these should be picked up on our end of course, but at least it gives us a better understanding of what's going on.

One more thing, can you do a simple query on table 1730 using query builder and show me how data.resultset_metadata.columns in dataset endpoint looks like for this query request:

Specifically do columns here have fingerprints or not?

If the newly connected DB has all the fields and all the fields have a fingerprint, I suspect the state in the MB database got subtly corrupted and/or out of sync with the DB at some point. Did you do any changes to the dbwh schema since connecting it to MB? Perhaps renamed a table or some such? In general these should be picked up on our end of course, but at least it gives us a better understanding of what's going on.

No it's clearly not the case. We still have fingerprint missing on the new connections, even after some relaunch of db scan.

@Nico-P-FR Can you post "Diagnostic Info" from Admin > Troubleshooting?
I was debugging an issue, where the warehouse (Panoply using Google Sheets) returned a value N/A one time for a float column, which somehow messed up the fingerprinting, so binning wasn't available: https://discourse.metabase.com/t/latitude-and-longitude-fields-wont-autobin/9806 - and that's likely what most people in #7782 have encountered too.

logs scan DB 111.txt

Completed step 'fingerprint-fields'
Start: 2020-06-30T11:39:40.220285Z
End: 2020-06-30T11:39:46.471313Z
Duration: 6.3 s
Fingerprint updates attempted 417, updated 35, no data found 382, failed 0

After this new scan (and drop of the table 1730) we have 394 fields "active" without fingerprint on this db id in metabase db.

Looking at the log, it seems fingerprinting of one table failed in its entirety, table 1685. Are there fingerprints missing on any fields in other tables? Above I was wrong, there is a situation where a field might not have a fingerprint that is completely valid: if the table has no data. Disregard those.

Yes I finally came to the exact same point : empty tables. I have analysed more deeply the list of all fields without fingerprints in our DB we still have and most of them are on table without any lines. We have :

• some fields on empty tables (without any lines / data at all)
• a field with a comma in name, I am not sure about if that play a role but I have cleaned it
• the case of table 1685 : it's the case we talk yesterday at this post. But for these table and maybe few others it's a problem around persistance of metadata somewhere because fingerprint works properly on this fields in the duplicate connection

So finally I think at the beginning of this thread we have multiple problems but now with all the cleaning operations we did and maybe with an improve in last MB version to not block on only 1 field error as you said it seems to works on all fields except on these empty table and on some specific table with a problem of refresh on fields name with/without capital letters but it's in fact before the fingerprint scan.

Thanks a lot for your help. I will let you now if I notice another thing around these topics.

@Nico-P-FR Thank you for helping debug and providing a lot of information!
We are investigating a lot of the issues around the sync-process and it seems likely that you were experiencing multiple different issues, some of them fixed in latest 0.35.4 release and others in upcoming release.
You were likely experiencing #7923 too.
Closing this issue, since the remaining problems are covered in other issues.