I'm attempting to add data to Tableau from Oracle but am getting the following error: Error "ORA-00972: identifier is too long. This error is because I'm attempting to use a column that is longer than 30 characters. I know that one fix for the issue to change the name in Oracle to shorter than 30 characters. Unfortunately, I can't do this myself and it will take the team that can do this longer than I'd like to wait so I was wondering if there are any workarounds to this issue.
I have already read the following page from Tableau: https://kb.tableau.com/articles/issue/error-ora-00972?signin=0f7d7b7f02b5d408316cdf9e3b03eef
An ORA-00972 means you are using a database column or object identifier name that is too long, as #tejash said in the comments. When you see this error in Tableau specifically, it only happens because the dimension or measure in Tableau has been renamed to be longer than 30 characters. It's an easy mistake to make because the Tableau UI doesn't prohibit the longer name.
I know that one fix for the issue to change the name in Oracle to
shorter than 30 characters. Unfortunately, I can't do this myself.
Because Oracle would have never let the name be longer than 30 characters when the column was created, there is nothing to fix in Oracle. You must fix it in Tableau and this is something you can fix yourself: rename the dimension or measure. There are a number of places this is possible and all follow the same principle (just different screen layouts) so I will describe the one I'm most familiar with. On any worksheet, on the left-hand pane where you see the dimensions and measures, right-click on the dimension or measure you need to rename and choose the "Rename" menu option.
Related
I'm having a strange issue with exporting/updating/importing data in our on-premises Dynamics 365 (8.2). I was doing a bulk update of over 3000 records by exporting the records to an Excel workbook, updating the data in a specific column, then importing the workbook back into CRM. It worked for all of the records except 14 of them, which according to the import log was for the reason that "You cannot import data to this record because the record was updated in Microsoft Dynamics 365 after it was exported." I looked at the Audit History of those 14 records, and find that they have not been modified in any way for a good two months. Strangely, the modified date of the most recent Audit History entry for ALL 14 records is the exact same date/time.
We have a custom workflow that runs once every 24 hours on a schedule that automatically updates the Age field of our Contact records based on the value in the respective Birthday field. For these 14 records, ALL of them have a birthday of November 3rd, but in different years. What that means though is that the last modification that was done to them was on 11/3/2019 via the workflow. However, I cannot understand why the system "thinks" that this should prevent a data update/import.
I am happy to provide any additional information that I may have forgotten to mention here. Can anyone help me, please?
While I was not able to discover why the records would not update, I was able to resolve the issue. Before I share what I did to update the records, I will try and list as many things as I can remember that I tried that did not work:
I reworked my Advanced Find query that I was using to export the records that needed updated to return ONLY those records that had actual updates. Previously, I used a more forgiving query that returned about 30 or so records, even though I knew that only 14 of them had new data to import. I did so because the query was easier to construct, and it was no big deal to remove the "extra" records from the workbook before uploading it for import. I would write a VLOOKUP for the 30-something records, and remove the columns for which the VLOOKUP didn't find a value in my dataset, leaving me with the 14 that did have new data. After getting the error a few times, I started to ensure that I only exported the 14 records that needed to be updated. However, I still got the error when trying to import.
I tried formatting the (Do Not Modify) Modified On column in the exported workbook to match the date format in the import window. On export of the records, Excel was formatting this column as m/d/yyyy h:mm while the import window with the details on each successful and failed import showed this column in mm/dd/yyyy hh:mm:ss format. I thought maybe if I matched the format in Excel to the import window format it might allow the records to import. It did not.
I tried using some Checksum verification tool to ensure that the value in the (Do Not Modify) Checksum column in the workbook wasn't being written incorrectly or in an invalid format. While the tool I used didn't actually give me much useful information, it did recognize that the values were checksum hashes, so I supposed that was helpful enough for my purposes.
I tried switching my browser from the new Edge browser (the one that uses Chromium) to just IE as suggested on the thread provided by Arun. However, it did not resolve the issue.
What ended up working in the end was Arun's suggestion to just do some arbitrary edit to all the records and exporting them afterward. This was okay to do for just 14 records, but I'm still slightly vexed as this wouldn't really be a feasible solution of it were, say, a thousand records that were not importing. There was no field that ALL 14 Contact records had in common that I could just bulk edit, and bulk edit back again. What I ended up doing was finding a text field on the Contact Form that did not have any value in it for any of the records, putting something in that field, then going to each record in turn and removing the value (since I don't know of a way to "blank out" or clear a text field while bulk editing. Again, this was okay for such a small number of records, but if it were to happen on a larger number, I would have to come up with an easier way to bulk edit and then bulk "restore" the records. Thanks to Arun for the helpful insights, and for taking the time to answer. It is highly appreciated!
When you first do an import of an entity (contacts for example) you see that your imported excel contains 3 hidden columns (Do Not Modify) Contact, (Do Not Modify) Row Checksum, (Do Not Modify) Modified On.
When you want to create new instances of the entity, just edit the records and clear the content of the 3 hidden colums.
This error will happen when there is a checksum difference or rowversion differs from the exported record vs the record in database.
Try to do some dummy edit for those affected records & try to export/reimport again.
I could think of two reasons - either the datetime format confusing the system :( or the the community thread explains a weird scenario.
Apparently when importing the file, amending and then saving as a different file type alters the spreadsheet's parameters.
I hence used Internet Explorer since when importing the file, the system asks the user to save as a different format. I added .xlsx at the end to save it as the required format. I amended the file and imported it back to CRM..It worked
For me it turned out to be a different CRM time zone setting for the exporter and importer. Unfortunately this setting doesn't seem to be able to be changed by an administrator via the user interface.
The setting is available for each user under File->Options->Time Zone.
I have a requirement where 300 columns had to be processed. I am trying to achieve this using IG automatic row processing (DML). When writing the code in the editor I get a error stating 'Value too long by 2015 characters'.
I suppose this is an Oracle Apex limitation. Can someone please share their views on this?
When writing the code in the editor ...
I'd say that your problem isn't related to number of columns, but a large query which can't fit into "SQL Query" item of the Page Designer.
Which Apex version do you use? I can't tell for sure (as I don't know it), but my impression is that Apex up to version 4.2 had that item limited to VARCHAR2(4000) so - if your query is larger than that, it won't fit (such as in your case - query you wrote is 2015 characters longer than the maximum size the item allows). In 5.x version, you can put a whole lot of query into the item (as if it was modified to a CLOB).
Now, as you use Interactive Grid and it appeared in 5.x version, huh ... maybe what I wrote above isn't entirely true. Unfortunately, you can't switch to a query whose source is a function that returns query (such as in Classic Reports), as you could write a (stored) function and simply call it from Apex.
As you said that you used automatic row processing, did you put too much code somewhere in there?
On the other hand, I Googled a little bit, looking for limit of column numbers in the IG - couldn't find anything official, but someone complained (here, on StackOveflow) that they tried to create an IG with over 100 columns, and it didn't work.
So, yes - maybe you hit the limit, but I can't confirm it. Hopefully, someone who knows Apex better will be able to assist. Alternatively, consider asking the same question on OTN forums, as people who designed Apex answer questions there.
We use VBA to retrieve data from an Oracle database using the Microsoft.ACE.OLEDB.12.0 provider.
We have used this method without issue for a long time, but we have encountered a problem with a specific query of data from a specific table.
When running it under VBA, we get "Run-Time error '1004': Application-defined or object-defined error. However investigating further, we find the following:
The queries we run are dynamically generated, and how we handle them is to read the results into a variant array, then output that array into Excel. When we step-through our particular query, we find that one specific database field is "blank": The locals window shows the value to be completely blank: it is not an empty string, it is not a null, it is not zero. VarType() shows it to be a decimal data type, and yet it is empty.
I can't seem to prevent this error from locking-out:
On Error Resume Next
...still breaks.
if (isEmpty(theValue)) then
...doesn't catch it, because it is not empty
if (theValue is nothing) then
...doesn't catch it because it is not an object
etc.
We used the SQL in the a .NET application, and got a more informative error:
Decimal's scale value must be between 0 and 28, inclusive. Parameter name: Scale
So: I see this as two issues:
1.) In VBA, how do I trap the variant datatype value-that-is-not-empty-or-null, and;
2.) How do I resolve the Oracle Decimal problem?
For #2, I see from the Oracle decimal data type, it can support precision of up to 31 places, and I assume that the provider I am using can only support 28. I guess I need to Cast it to a smaller type in the query.
Any other thoughts?
So, a company I work at has an older ERP system that uses FoxPro 4 or 5. There is no support for the system, so I am trying to use skills that I don't possess. I'm good with Servers and even networks, but not coding. I have attached links to two similar errors that are occuring to two different users in different departments using different computers. Your help would be appreciated.
FoxPro Error 1
FoxPro Error 2
Well, the problem is exactly what it says on the tin. It looks like the issue is with the field BODY.COST. The field will have a maximum capacity, for example N(12, 2) would allow numbers up to 999999999.99 to be stored in it.
The system is attempting to put a number that is bigger than the defined capacity into this field. You can see it is a GATHER MEMVAR statement in both cases. This statement takes memory variables and updates a database table using them. One of the memory variables has ended up with a bigger number in it than the database field (looks like BODY.COST) that is intended to store it has capacity for.
Beyond that, with no support and no source code you are really limited to looking at what the user is trying to post and seeing if that gives you any clues. Is that the extent of the error dumps or are those just snippets?
The messages are saying that you are trying to store a larger value than the field would accept. This happens with numeric and float fields in Foxpro. In both of the messages, the table was indirectly aliased as "BODY" and the problematic field is "COST".
As a solution, using VFP5 (do not use a later version - there weren't VFP4), you can make all the numeric and float fields to either Currency or Double data type.
Currency has a high certainity and suggested for monetary values (need not be monetary). It is in the range of –922337203685477.5808 to 922337203685477.5807. That range is actually above what a numeric/float field can support.
If you think that is not enough range, than you can use double (something like -10^327 to 10^304 - VFP has a precision of 15 digits, you lose precision beyond that).
I would go with Currency.
I am trying to remove all references to a table from a Crystal XI report. Crystal is telling me that a column from that table is currently being used, because there is a little green check mark over the field in the field viewer. Also, if I try to remove the entire table, I get a warning. The warning is almost useless though because it doesn't tell me where the field is used. Now, back when programmers were real programmers, and mice were things cats chased, I could just grep a directory or file and find all references to a variable I was interested in. But how do I do this in Crystal? I have already tried exporting the report to a Report Definition, which helped find some instances of the troublesome field. Unfortunately, that format does not include all formulas, just some. Please tell me I don't have to buy a third party app (or write my own COM thingy) just to do this seemingly simple thing.
EDIT to add details about tangential point:
In case anyone is wondering, I am not crazy - I have duplicated the issue where a formula's definition does not show up in the exported Report Definition. I created a new blank report, created one formula named stealth that returns 1234. I then used that formula in the Section Expert for the details section, in the "suppress" formula, setting it to {#stealth} == 0. the use of the formula shows up, but not the definition. So when my unwanted column was used in the formula, I was not be able to find it! Here's what the rpt def looks like (after deleting some blank lines):
Crystal Report Professional v11.0 (32-bit) - Report Definition
1.0 File Information
Report File:
Version: 11.0
2.0 Record Sort Fields
3.0 Group Sort Fields
4.0 Formulas
4.1 Record Selection Formula
4.2 Group Selection Formula
4.3 Other Formulas
5.0 Sectional Information
5.1 Page Header Section
Visible, Keep Together
5.2 Page Footer Section
Visible, New Page After, Keep Together, Print At Bottom of Page
5.3 Report Header Section
Visible, New Page Before
5.4 Report Footer Section
Visible, New Page After
5.5 Details Section
Visible
Subsection.1
Visible, Keep Together
Format Formulas
Visible: {#stealth}= 0
If all else fails ...
File -> Export -> Export Report, then choose the Report Definition (TXT) option.
That will give you a plain-text representation of every element of the report. You can grep or CTRL-F or (insert search tool of your choice) through that. "Find in Formulas" usually works, but I've had to go the export route a couple of times, for no apparent reason.
Edit: Of course, if I'd bothered to completely read your post, I'd see that you've already done this.
Very curious.
If you right click on the field in Field Explorer and select Find in Formulas, it should bring up a dialog listing all of the places it is being used in formulas. On the left hand side of the dialog is a tree of all the possible places it could be, including oddball places like record selector and page formatting functions. Unfortunately, it does not seem to list running total fields.
EDIT: Oops, all the places it exists is listed at the bottom of the dialog; the tree view is the entire "DOM" of the report.
I know this is an old post, but...
Not knocking the Find in Formulas, it's been saving me today, but i was having trouble finding the last instance of the field. Even after all of the formulas and the droppings on the report were taken care of, I still had one lone use hiding somewhere.
I found it hiding as a Subreport Link. Right click on the Subreport -> "Change Subreport Links..." and there was the culprit. Dropping in this post because I figured someone else might have this problem too.
Fields can also sometimes be hiding within "Record Sort Expert"
Responding to an old post, but ran into a similar issue. I had a group based on the formula I wanted to delete that had a specified order. When I changed the grouping to a different field, the specified order remained. When I removed the specified order, my formula could be deleted.
This was tested on XIr2...
You change the tables datasource through the "set datasource location" dialog. Now, when it goes into the column mapping mode, uncheck match-type and pick a new column that would cause an error in a formula. (i.e if the column you're looking for is a string replace it with a datetime column). Go to the preview and you should get an error box like "A string is required here.", close that error and up pops the offending formula!
One more suggestion. After following a lot of the suggestions here, my report was still telling me the formula was in use. I had to close the report. When I opened it again, the check mark was gone and it let me delete it. This was on Crystal v 11.0.0.1282
In my case the Formula Field happened to be part of an old Running Total Field, which itself was not included in the report. Once I deleted this old Running Total Field I could delete the unused Formula Field.
Very late, but i use CR 2008 (12.3.0.601) and just today (6/16/2015) i am trying to document only the formulae of my report. I knew about exporting the Report Definition, and Finding a Formula in all Formulae. But there are about 50 Formulae. I discovered that the exported Report Definition didn't document all of my Formulae, but I didn't bother to uncover the logic behind that; instead, i plopped all Formulae into a section, then exported the Report Definition. Voila. Of course, i still need to cull all the unnecessary definition elements. But at least i have all Formulae.
So with all the great selections.. I still had one instance hiding from me. I found out where it was by creating a clone of the data table and renaming\deleting the field.
I then used the "Set Database Location" as suggested above to point to my new table. It did error out when it could not find that field but still didn't tell me where it really was (it just said report field).
I did NOT map it and clicked continue which deleted the field from the report. I then mapped it back to the real table and I was good.
In my case, there was a Chart, and the field was being used as one of the "on Change" fields.
Although an old post, this functional gap still exists within Crystal Reports itself. We have a fully functional 14 day trial of our third party software that uses the latest Crystal.net API to search for plain text within a library of Crystal RPT files in one fell swoop. Also searches the data saved within reports, and text within labels ... as well as datasource behind all your reports ( stored procedures, views, and table data ) with support for SQL Server, SQL Azure, MySQL, Oracle, Amazon RDS, DB2 and Access.
More info and trial downloads at http://www.finditez.com
Note, you will need to download and install the compatible SAP Crystal.net runtime connector for searching your RPT file library.