Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

2004 Ideas

Check if correct database is selected in generated scriptsOpen

Regularly I execute scripts generated during the SF generation process in SSMS. This is all fine, unless one has the wrong database selected… This happend to me once when I wanted to execute the VIEWS script in SSMS……. with the SF database selected. One of the first things that'll be done is deleting ALL views in the current database! As you can imagine, all kind of defects were detected in the SF afterwards, and in the end I had to rebuild the SF from the installation scripts (a restore from the previous night would result in the loss of all work that day from a couple of developers and designers).  When the script is executed on, for example, a Navision production database all hell will break loose. So my idea: generate a piece of code in the beginning of each script like below (BAS_DMS_WORK would be replaced by the SF with the projects database). I tested it in SSMS and it works flawlessly. Is this something that can be built into the SF? Will it work when running the additional lines from within the SF GUI?   print 'Check if current schema is correct'goif DB_NAME() <> 'BAS_DMS_WORK'begin print 'Fatal error, wrong database selected for projectversion!' set noexec onendprint 'Ok.... All clear, let''s continue'go-- Rest of generated script, like dropping ALL views...... This won't execute in SSMS the wrong database is selected.select * from work_orderselect * From part_alternative where part_id = 117396-- last line of the generated script-- Turn execution back on; only needed in SSMS, so as to be able to run this script again in the same session.set noexec off                  

René WSuperhero

Override delete and copy with a custom taskMerged

TL;DR: We want a custom task bound to the standard copy and delete functions (in the ribbon and buttons).As we're tempting to roll out the software without having to explain the functions in the ribbon, we continuously encounter the same issue that end users don't understand the copy task and the delete task (why it's blocked or doesn't work as expected). It's a difficult one...Please consider we're an ISV and targeting users on which we don't want and can train in person. We hope by changing this our users more often get a 'as expected' experience.CopyingThe copy button creates by default a new record based on the selected record. This is in a certain amount of cases very useful. For example if you want to copy a purchase order line, adjust some cells and continue. There are also a lot of situations where the meaning of the copy button is interpreted differently: Users expect a copy of a record including the (partial) details. As example you could imaging copying a purchase order: The user probably wants to change some values such as a order date, but remain the details.I'm aware that this does something with the consistency of the Copy button. But explaining the difference also is not easy: Why is there a task to copy defined, and a generic button copy? End users without knowledge of the Thinkwise platform don't know, and probably will never want to know.We would like to override the generic copy button with a custom task implementation. The task doesn't "Add" a record immediately, but the task pop-up shows up instead.DeletingWe apply the default 'no action' model. Applying a cascading deleting model is a bit tricky, we prefer not to do*. This causes that in all subjects with details, the default delete is disabled and there's a task defined. This is confusing for users: Why is the delete button disabled, and is there a task doing exactly the same? (As for a end user point of view: why don't you enable the delete button in the ribbon?)Another major benefit of the task, is that it's currently multi row supported (multi row task execution). This has a great benefit on performance, where as the generic delete does remove 1-by-1 and can be painfully slow.We would like to override the generic delete button with a custom task. This task must be multi row supported and has a custom implementation regarding what to delete. I could imagine a customer dialog entering some parameters could be useful for some use cases.*: Yes, you can probably change your complete model to 'cascading delete', but I think it's dangerous to do. In fact, the SF also does not apply a cascading delete, probably with a reason?