Dynamic Package - Default what does it do

HI,

It might help the user if a single liner of what does the module do will be useful to the user. For me and you it's easy to remember what it does , but new users have a tendency to be confused by everything. It will add unnecessary overload to you the designers too I understand that 

 



An example of what others have done for inspiration

 
 

Yes that would be a good addition plus we can translate it into multiple languages.

One thing I wanted to discuss with you is logging.

At the moment it is difficult to use it for debugging or tracking variables changes .

Do you have any suggestions? 

HI,

Regarding logging, I might be not understanding what you've asked me but I can share my views with limited experience on running scripts. 

two types

1. When I am actively troubleshooting , I have mentioned it's difficult to understand in real time at times what's happening , specially if scripts are being utilised , I have written a macro which simply asks me for a package id ,
opens a new command line with "C:\Program Files\DB Software Laboratory\Advanced ETL Processor Enterprise\aetlcl.exe" {{packageID}}
1.1 Maybe run this package in command line option can be useful

2. When checking logs later , passively, the number#1 irritation for me is that after I identify an error if any , I cannot copy it , the log has to be opened up in notepad
 

3. Logs also contain the entirety of script which has been run, it also provides a sequence but might not be providing any value as any debugging has to be actively built into the script
 

3. The variable changes happen very fast when you run a package dynamically , and it becomes difficult to remember what happened , if you show it in logs , it will become unholy LONG with each variable change . 

Is this what you meant about Logging or something else 
 

I think we have 3 issues where

1 Not enough logs.

At the moment there are separate logs for of some of the package actions for example transformations import and sql scripts bit not all of them.
Most of the package actions write log data into single package log, that makes it difficult to find the problems.

I think every package action must have a separate log.

2 How logs are stored.

Right now all log files are written into a single folder, that makes working with logs slow. (Just try creating 1,000,000 files inside single folder)

The better option is to use  sub folders, EG:

logs folder => execution date => Execution Code => Action=> Action execution log

3 It is difficult to troubleshot individual action failures.

I think one of the possible options is to add execution log tab to package action dialogue

    

Highly in agreement of #1 , I haven't faced anything on 2 yet , since I keep deleting logs on weekly / monthly basis. I assume high complexity in sending errors to beloved SQL database which can be opened with some inbuilt viewer ? Then a query can be provided which can 'cleanup' the logs daily/monthly/quarterly/annually?

I would also like to highlight , whenever the structure has changed , like below , user should be able to 'see' the previous structure in place for troubleshooting , It's a generic message where user has to 'think' which column structure changed , this info exists somewhere already (how is AETL 'knowing' about the change?)