I created a table in SAP via se11, then I used the table maintenance generator. Then I transported the changes from development system to q-system.
Now I want to maintain the table via sm30. This works in the DEV system. I just get a warning: "This table is cross-client". But editing works. In the QA system it does not work. I get:
Changes to repository or cross-client customizing are not permitted
How to make a cross-client table editable?
The table's delivery class is C. The table's data class is APPL2. No there is no column MANDT (on purpose).
I know that I can edit this table with &SAP_EDIT in se16n, but I would like to avoid this dirty hack.
This is not allowed because the setting for Cross-Client Object Changes is set for this client in such a way.
Go to SCC4 select your client and change the following setting if you can and are allowed to.
I found a way to make cross-client editing via sm30 possible:
Use "table maintenance generator" (via se11). Then option "recording routine", there you need to set "no, or user recording routine".
Then you are able to edit tables via sm30 which are cross-client tables (without column MANDT).
Related
Epicor - what a beastly creature!
Epicor asking for password after making a table change, any idea why?!?!
We removed the relationship from the (part table) and set up a criteria, instead. Now it is asking for a password, which should not be happening.
the login happens when I try to run the report. I am trying to figure out what I did to aggravate Epicor. The table was already there. I removed the relationship (part table) and added a criteria, instead, otherwise, that is exactly what I would have done. The only reason that I did not add a table to a report data definition, like I originally wanted to is because the parts table could only be added once. Which is why I removed the relationship and added a criteria, instead.
From your description, it sounds like the problem is related to the xml generated by Epicor for a non-BAQ based report data definition. Crystal and SSRS reports ask login information when either there is more than one datasource is referenced in the report, or there is improper relationships defined.
Note:
If you are not a report developer and you have modified this in an attempt to change the end data, I recommend you contact the report developer responsible for maintaining these before proceeding. Otherwise, read on.
Based on my experience, I would say if you are confident in the new relationship structure you have in the report data definition, the solution to this problem is likely within the report itself. Generate an xml file by running a test report, then open the .rpt (or .rdl) associated with this report and set the datasource to the new xml file. This should update the new xml schema used as the datasource. Even if none of the fields were changed in the data definition, the datasource schema definition that is stored in these files define exactly the data formatting that the report expects to receive when it is opened by Epicor.
If that doesn't solve the problem and you are using Crystal, the xml relationships may be defined in a way that will effect the way the data is displayed, which can be adjusted by using database expert->links tab in crystal. You should reconnect all of the links to match the report data definition within Epicor.
If none of that works, open up and view the xml file.
It is not unheard of for report data definitions in Epicor to break behind the scenes when altering relationships, and the xml file generated by the test report may not be a fully-qualified xml file. I have seen many xml files that do not have elements closed, etc. that will cause various problems when attempting to run the report. In this case, my recommendation is to create a completely new report data definition (do not copy), and re-enter all of the parameters that existed in the former definition. Repeat the refreshing of the report datasource as described above and this problem should be fixed.
I've got a large amount of access databases that need to have the same table design changes (and a few new tables created) in each of them. Is there any way to take my most recent (properly designed) database, export the design properties, and import them to each of the other databases overwriting changes and creating any new fields, tables, etc. as needed?
My research has only led me to the Database documenter which seems to only be helpful in cases where I'd manually update the properties. I also know I could potentially copy each table over manually specifying 'Structure Only' for each case but that'd be a rather daunting task and I'm unsure what exactly would be copied using this method.
Let me see if I have the outline...
Open Proper.mdb
For each OtherMDB in Folder1
Open OtherMDB
for each ProperTable in Proper.mdb
If ProperTable is absent from OtherMDB
Add ProperTable to OtherMDB
Else
For each Field in ProperTable.Fields
If ProperField is absent from OtherTable.Fields
Add Field to OtherTable
Elseif ' is this a possibility?? wanting to change field type?
ProperField.Type <> OtherTable.Field("xx").Type Then
Change Field.Type
endif
Next Field
Endif
Next Table
Close OtherMDB
Next MDB
I found a utility called DBWeigher which is able to analyze and compare two access databases and automatically generate the necessary VBcode to update the changes between the two. From here I quickly ran through the changes manually and was able to see firsthand what changes would be made prior to running them through the DBConsole.
For anyone trying to update older access databases (especially when they're at different stages and could have some variances), I can't suggest checking this lightweight utility out.
I added field to Progress databyse by
ADD FIELD filedName on TABLEName...
and now I want to change/modify this field (PRECISION or FORMAT or something else...)
What syntax will be correct ? I tried like this:
UPDATE FIELD
MODIFY FIELD
ALTER FIELD
I tried aldo sql notation: alter table
but nothing works.
Could You help me please with syntax to modify field ?
If you are using the 4GL engine (you are using _progres or prowin32 to start a session) then you want to use the "data dictionary" tool to create DDL. You run "dict.p" to access that tool. i.e.: _progres dbName -p dict.p
This will allow you to create tables, define fields and indexes etc. If you want to export the definitions you use the "admin" sub-menu to dump a ".df" file. You can manually edit the output but you need to know what you are doing. It is mostly obvious but it is not documented or supported.
Do NOT imagine that using SQL from within a 4GL session will work. It will not. The 4GL engine internally supports a very limited subset of sql-89. It is mostly there as a marketing ploy. There is nothing but pain and agony down that road. Don't go there. If you are using _progres or prowin32 you are using the 4gl engine.
If you are using SQL92 externally (via sqlexp or some other 3rd party SQL tool that uses an ODBC or JDBC connection) then normal SQL stuff should work but you might want to spend some quality time with the documentation to understand the areas where OpenEdge differs from Oracle or Microsoft or whatever sql dialect you are used to.
Tom, thanks for Your answer.
I use OpenEdge Release 10.1A02 on Linux.
I can make a dump.df file and I can also add new table from file (similar df).
But why I cant modify any added fields ? Ofcorse i can use "p" editor and do it manually from menu Tools/Data Editor/Schema and add new table but it's risky if I tell database administrators to do it manually on each enviroment (specially on production).
if exists syntax:
ADD FIELD filedName on TABLEName...
why there is no
Modify FIELD filedName on TABLEName... ?
Bartek.
Just in case - here are some working examples of .df files in OE 11.3 (could be they are valid in other versions too):
Rename column:
RENAME FIELD "OldName" OF "TableName" TO "NewName"
Other properties:
UPDATE FIELD "FieldName" OF "TableName"
FORMAT "Yes/No"
LABEL "Label"
VALMSG "Validation message..."
Of course the database must be shut down first (apply those changes in single-user mode).
I need to store data's change histories in database. For example some time some user modify some property of some data. The expected result is we can get the change histories for one data like
Tom changed title to 'Title one;'
James changed name to 'New name'
Steve added new_tag 'tag23'
Based on these change histories we can get all versions for some data.
Any good idea to achieve this? Not limited to traditional relation database.
These are commonly called audit tables. How I generally manage this is using triggers on the database. For every insert/update from a source table the trigger copies the data into another table called the same table name with an _AUDIT appended to it (the naming convention does not matter, it's just what I use). ORACLE provides you with something called journal tables. Using ORACLE designer (or manually) you can achieve the same thing and often developers put a _JN to the end of the journal/audit table. This, however, works the same, with triggers on the source table copying data into the audit table.
EDIT:
I should also note that you can create a new separate schema to manage just your audit tables or you can keep them in your schema with the source tables. I do both, it just depends on the situation.
I wrote an article about various options: http://blog.schauderhaft.de/2009/11/29/versioned-data/
If you are not tied to a relational database, there are things called 'append only' databases (I think), which never change data, but only append new versions. For your case this sounds kind of perfect. Unfortunately I don't know of any implementation.
I have a SQL database where one of my fields 'Status' has one of 10 entries in it (not from a dropdown list). I let some people have access to the data through an Access database, they can add and modify entries.
My question is, in Access, how can I make it so that the 'Status' field is a drop-down list from which the users can choose from (the 10 entries which are already in the SQL database)? It would be easier for them and also mean that mistakes cannot be made.
Many thanks
Scott
The usual way to do this is to use a combo box on a form with the row source taken from the look-up table and the bound column set to the field (column) of the table to be updated.
In Access you can add lookup information to a column. That will automatically display a dropdown list.
Step 1: Start the lookup wizard:
Step 2: After the wizard, the lookup settings should look like this:
Step 3: When your users open a table, they should see the dropdown box:
In addition to the solution described by Andomar you must not use another table as the source for your lookup. You can also provide the lookup-values in a list, which is hardcoded in the table-definition. This is fine for simple scenarios where the lookup is something that is not likely to be changed.
Several issues here:
table datasheets are not suitable user interface for users.
you can create a saved QueryDef and if you view the properties of a field, the second tab is just like the second tab in table design, and allows you to use a combo box as your display type in your query. I would generally recommend against this, as, like table datasheets, a QueryDef is not a proper UI element, and if you use the saved query in other queries, you can run into the same problems that cause lookups in table fields to be such as bad idea.
you're building a UI, so use the tools that Access provides you for building a UI. That means a form. Your form's recordsource would have the bare data, and you'd create a combo box on your form that is bound to the field in the table behind your form, and displays the values from the lookup tables. There's a wizard to step you through this. If you like the look of datasheets so much (column sizing, sorting, show/hiding are all features that are nice in datasheets), you can set your form to display as a datasheet.
My advice is that for building a user interface, use the tools Access provides for creating user interface. In my opinion, a dropdown list belongs in a form, and nowhere else. While I occasionally might add one to a query for quick-and-dirty editing, I would never do that in objects that users are going to use.