Thomas Ehret@CHEDSZURICH
01.02.2000 13:42
If I want to export data from a report in *.xls the following message appears:
SYNTAX ERROR IN FIELD DEFINITION (3292)
If I take *.DBF instead of *.XLS then the error message is:
field ‘ColBoDup_1’ already exist in table ‘Query1’ (3380).
If I take *.TXT the export will be created without warnings.
Who can help me ?
Thomas Ehret.
Listserv Archives (BOB member since 2002-06-25)
"Error "field name already exists in the table Query1 (3308) when exporting to .DBF.
the name of the fields in a .dbf file must be 10 char maximum. Maybe the name of your objects are longer than this, when this occur BO Truncate the name at the number 10 character. So two different objects like: “Revenue per Country” and “Revenue per City”, looks like “Revenue pe”, so when Bo tries to create two fields with the same name, fails. Try to change the name of your objects.
Listserv Archives (BOB member since 2002-06-25)
SYNTAX ERROR IN FIELD DEFINITION (3292)
BusinessObjects is using Microsoft’s Data Access Objects (DAO) technology to provide this feature. This technology has some limitations.
This error message appears when:
-special characters are used in object names, including
[ ] = & @ 0 $ % * < > , : ; ? ! ’ # ~ $ 5 + # . / \ ’ ( ) { } "
-object names match Microsoft Jet database engine reserved words, including
DATE,SELECT,UPDATE,BETWEEN,SET, CURRENCY and INSERT.
****RESOLUTION
Do not use special characters or reserved words in object names.
A fix has been provided in the service pack 2 ( 4.1.2 ) which allows the following characters in object names:
The fix converts these characters to an underscore ( _ ) in the Excel file.
Listserv Archives (BOB member since 2002-06-25)
We have a group of users who want to take their data into MS Access, they wanted to use the “export to RDBMS” option, but we are trying to avoid allowing any users to create personal connections. As an alternative I suggested they export to a file (.dbf) and then they could open up directly in Access. Problem is the export errors out because several of the objects have the same first 10 characters. I know changing object names is one option, but as I mentioned several of the objects would need to be changed and I am try to avoid this. Any other suggestions. - thx
jswoboda 
(BOB member since 2002-06-20)
Save the BO microcube as a flat *.txt file. Then import this *.txt file into your other application.
Out of curiosity:
What would your users be able to do with the data in MS Access that they cannot do in BO?
Andreas 
(BOB member since 2002-06-20)
I did suggest saving as a .txt or .csv but then you have to go through the wizard to open it up and apparently this is not seamless enough for them.
Andreas, I am not sure what they are trying to do. I did ask but did not get a straight answer other than how important it is to “streamline the process” and get this data into Access with all their other data (BO portion of this process to be run daily). This is one of those projects where they are trying to side step the IS dept. and have brought in outside consultants. And although, they are officially not going through our Department I sure have been getting a lot of calls/emails about this.
Irregardless of the project or purpose, I am trying to provide them with a viable solution. The .dbf thing threw me for loop, I tested it and everything looked good until they sent me their query it errored out. I hate it when my suggestions don’t work. 
Truth of the matter is, there is probably a consultant over there telling them all the magic he/she can do in Access; however, I do believe they are pulling data from several sources and using Access as a central repository for the data.
Sorry… I probably provided a lot more info than you wanted to know, but I could go on and on…
jswoboda (BOB member since 2002-06-20)
I think the best approach would be to analyze WHAT they (the end users) really want to do with the data and then propose possible solutions…
Maybe, a meeting with a power end-user, the consultant, and a BO expert would be fruitful.
Andreas (BOB member since 2002-06-20)
Sounds like a good ideal, problem is they have not submitted a project request, which they have been asked to do on multiple occassions (when it was determined that they would need the assistance of IS dept), and I can not allocate my time until they do so.
jswoboda 
(BOB member since 2002-06-20)
Best approach would be to accidentally remove the Access database and point out the versatility of BO 
I agree, the meeting would be useful (not least to ascertain the consultant’s daily rate and point out the cost savings…)
Question?
Is it possible to do more with joins and SQL in Access? Can you fill in non-existent data fields in Access vs. BO? I haven’t researched this much so I was just inquiring.
Thanks,
Rich
o324712 (BOB member since 2003-02-12)
This is a very timely topic. I have a meeting this afternoon to visit a potentially hostile group of MS Access users. We are deploying BusObj as the reporting tool of choice for a rather unstructured database. The former tool was very limited in its capabilities, and in some cases MS Access has been used to compensate for those limitations. It was unsupported of course, but not difficult for a semi-knowledgeable user since they have their own Oracle ID. Well, with BusObj individual users do not (in our deployment) have their own Oracle ID, and our ultimate “stick” to convert from the old tool to BusObj is to turn off the Oracle ID, which won’t be popular with the MS Access users.
My approach of course is to show that the reporting can be done with BusObj, and that it will be a supported tool (help desk and so forth). My questions for the group will be to ascertain if there are legitimate reporting needs that BusObj can’t meet (unlikely), or if there are other processes in MS Access (like data entry / transformation) for which BusObj is not designed. To say the least, it should be an interesting meeting 
Dwayne Hoffpauir (BOB member since 2002-09-19)