Is there any way to create import dynamically?

File name and location might change depending on the user login.

Yes, you are right. I fell asleep as DataEase functions are getting way too much :-)

Anyways, problem I am facing. My client running 8.1. So, I can only use what is available in that version.
They are into the application deep way too much. It will be really time consuming to update.
Of course, when client decides to update, we will.

But, I am using ExecDQL whenever possible. I do see, it is million times faster than classic DQL.
Again, problem with ExecDQL. We cannot check for syntax errors.....
So, I have to use DQL to create and check everything is working. Then copy and paste the code for ExecDQL use.

Again, problem with ExecDQL. We cannot check for syntax errors.- will this feature be enabled one day ?

Again Sleeping in class are we ;-)

Of course you can check for syntax, there is absolute 0% difference in the checking of Syntax in ExecDQL and "tradtional" DQL. You get the same "errors" in the same way.

The difference is that ExecDQL parse the code in runtime so you have to try to run it to check for syntax errors.

You can run it as a DUD i.e. it doesn't actually have to do anything.

Sometimes guys it is like you are repeating some old Mantra. "It doesn't work, it is not as I want it, It will not work, it will be buggy.."

Over and over again.

Open the eyes and look beyond and above. It is a long time since the above was true so instead of instinctively think that nothing has changed, think that it most likely have changed but I blinked and missed it.

The difference between us and the Sapphire team that developed DataEase is that we are the most advanced and heaviest user of DataEase today and that is the people that actually make the design decisions.

What do you think is the likelihood that we will spot the defect or need in the product way ahead of anyone else?

We will soon stop development of functionality in DE85 because it has more than enough already, and the problem now is that very few use the new stuff or even know of its existence....

So now the focus need to be on enabling the users to use the product.

Hallo there,

i think it may be a solution to use a dynamic var that stores the pathname u want to use.

depending on the user that is logged in. Check it by using "current user name".and than using concat to create it...

Hope this gives you a little idea to solve this problem.......

Markus

To make and ExecDQL editor with the same level of "complexity" as the Traditional (DFW) editor can be done in an hour by anyone.

Syntax checking is there and has always been there on the exact same level as for traditional DQL, only difference is that it does it before it run it rather than when you edit and save it. 

This is simply because you can edit and save it in normal fields, and then parse/execute it from anywhere.

SO the only thing one need to do is simply to do a trial execute of the code, which I for one always do.

Hi Markus,

That is a good idea. But, how do we use it in import ?

See the screen below;

Download Sample!

Hello Boys.

100 points for effort, and 0 for reality ;-)

Luckily a DBI is really just an XML file, so you can create your own and then you can simply use it.

<?xml version="1.0"?>
<Import>
<TableName>System - Info</TableName>
<DataFileName>C:\Users\LBG\Documents\My DataEase\ImportDefintionPlay\asdfasdfasdf</DataFileName>
<SourceTDFName/>
<ImportFileFormat>9</ImportFileFormat>
<DataOrder>1</DataOrder>
<RecordSeparator>13</RecordSeparator>
<ColumnSeparator>126</ColumnSeparator>
<RecordMatch>4</RecordMatch>
<BatchData>0</BatchData>
<AutoInsertDecimal>0</AutoInsertDecimal>
<IsSourceAscii>1</IsSourceAscii>
</Import>

Since it is not documented, you need to play a little with import definitions to see what the different switches means (like Separators etc, but it is quite self exlanatory).

See attached sample where we simply use LabelExecDQL to create a DBI on the fly.

Where the content is the body and the DQL simply list the content of some fields and replace the tags.

WOW!

I know DataEase can do anything :-)

There are so many undocumented features. Not sure if you will document them in the future or just find out as we go along.

Thank you.

On the same subject. I am trying to export using dynamic file name. 

I was able to do this long time ago. But, it seems to be not working now. Could you please see the screen below and tell me what is wrong?

In the following script, global variable value get passed via control procedure.

define global "gFileLoc" Text 100 .

for AssessmentPackets

;

list records

ID ;

CertFrom ;

DocTracker ;

SkilledCare ;

HHACare ;

PayorSource ;

Unq ;

PDFExists ;

PacketFile ;

DocTrackerTxt .

end

export to tFileLoc .

ID~CertFrom~DocTracker~SkilledCare~HHACare~PayorSource~Unq~PDFExists~PacketFile~DocTrackerTxt

.items

@f[1,1]~@f[1,2]~@f[1,3]~@f[1,4]~@f[1,5]~@f[1,6]~@f[1,7]~@f[1,8]~@f[1,9]~@f[1,10]

.end

Resolved!!

I thought I had enough rights. But, it was an issue with the local rights. As soon as I get the rights, everything is moving smooth.

Thank again for opening up the import dynamic feature.

Glad you fixed it yourself ;-)

Why you choose to do it this way when you can do it so much better and easier in ExecDQL is both worrying and depressing...he,he.

Did you know that if you were to export ex. 100.000 records this way it would take hours this way and less than a second in ExecDQL?

Take the leap from the dark ages into enlightenment, it will pay off at every junction.

To be honest, the first ExecDQL implementation was created EXACTLY for this reason. Needless to say it has moved beyond this later....

I know you were going to say that :-)

But, I have already converted all the DQLs into ExecDQL. By learning the hard way, yes it takes 100s of years...:-) using DQL export.

Only thing I see about DQL, we can use whatever field separator we want.

Been  sleeping in class again Arul? ;-)

It is a long time since ExecDQL surpassed traditional DQL when it comes to opportunities for both design on output, output methods and formatting of Exports.

ExecDQL even surpass DFD in this area (Export).

Default handling with no Body (formatting) argument is export as CSV with ~ as separator, and with list name as column header but it is ages (05.06.15) since we added output method and body formatting argument. (8.5.0.1815 - and you even commented on the blog....)

MemoExecDQL use a Memo as argument for the formatting and LabelExecDQL a Label etc. I used it in the sample for this request.

The nicest thing with ExecDQL that people try to forget is that it is 100% interpreted, which means you can automate the generation and then run the code.

As part of this exercise I made a simple app that generate on the fly the DQLs for exporting all the data in an application based on the status tables.

The possibilities are endless, but only if we grasp the bull by the horns...