Hi there!

How can I redirect the error messages from standard i/o to file? But the program is writing to the std I/O other messages.

Thanks!

LATte

How can I redirect the error messages from standard i/o to file? But the program is writing to the std I/O other messages.

Under Dos/Windows you have to use the djgpp redir.exe program. Under Linux, you can use

program 2>error.txt

Jonas

Hi...

I'm making a query to a Postgres database, but I can't use the "where" command, I mean, I need to do somethiing like:
query_s := 'select my_date from info where fecha>=1/1/2000';

	Right now I recive no information, but i I use
query_s := 'select my_date from info';
	Then there is't problem...
	What is wrong in my expression ??...

Thanks....

Ing. Morquecho Morquecho
Cedetel
Desarrollo de proyectos comerciales
Tel : 177-10-87
Cel : 177-00-87
e-mail :
e-movil :
Home Cedetel : http://www.cedetel.com.mx

"#define QUESTION ((bb) || !(bb)) // Shakespeare"

I'm making a query to a Postgres database, but I can't use the "where" command, I mean, I need to do somethiing like:

Shouldn't you put the date between double quotes? And possibly even use the data function? I.e.

query_s := 'select my_date from info where fecha>=date("1/1/2000")';

Jonas

Hi,

Version 1.1 can't compile a project if units exist. The compiler give up with code 10998 (sysutils.pp(37,9). When I clean the directory with delp first, it's no taken out of the CVS today.

Hinrich

Hi,

as far as I can see, Michael tried to fix the findfirst-problem. It seems to be working fine now, so you may close that bug.

Hinrich

Under Dos/Windows you have to use the djgpp redir.exe program. Under Linux, you can use

This depends on the shell. I use &> to redirect under 4DOS.

Marco van de Voort ( or )

I get it !!, this is the right sintax is:

query_s := 'select my_date from info where fecha>=''1/1/2000''';

Thanks...!

Ing. Morquecho Morquecho
Cedetel
Desarrollo de proyectos comerciales
Tel : 177-10-87
Cel : 177-00-87
e-mail :
e-movil :
Home Cedetel : http://www.cedetel.com.mx

"#define QUESTION ((bb) || !(bb)) // Shakespeare"

query_s := 'select my_date from info where fecha>=1/1/2000';

this query is invalid cause 1/1/2000 should be in "

Hinrich Donner wrote

Hi, as far as I can see, Michael tried to fix the findfirst-problem. It seems to be working fine now, so you may close that bug.

I've marked it as fixed.

Michael.

Hi,

> as far as I can see, Michael tried to fix the findfirst-problem. It seems > to be working fine now, so you may close that bug. I've marked it as fixed.

there is still a little problem:

findfirst('*.*',faAnyFile-faDirectory,sr) will return '.' and '..' as well, even the sr.attr is correct set to faDirectory.

Regards, Hinrich

findfirst('*.*',faAnyFile-faDirectory,sr) will return '.' and '..' as well, even the sr.attr is correct set to faDirectory.

AFAIK, that will most likely remain that way as well. The '.' stands for current directory, while the '..' stands for parent directory. Since, in essence, those two entries do indeed represent directories findfirst is returning the "correct" answer.

Jim

Realy? Why should I use faDirectory or other attributes if the function allways return everything?

Hinrich

Unless it is returning other filenames that aren't directories. "." and ".." ARE directories. The function works properly in that case. Now, if the function is returning text file and binaries, etc. when the faDirectory attribute is set then it is broken. But if it is only returning directory names and "." and ".." then it is working exactly the way it should.

Matt

In a message dated 12/8/00 1:04:26 PM Eastern Standard Time, writes:

<< >AFAIK, that will most likely remain that way as well. The '.' stands for

current directory, while the '..' stands for parent directory. Since, in essence, those two entries do indeed represent directories findfirst is returning the "correct" answer.

Realy? Why should I use faDirectory or other attributes if the function allways return everything?

>

Realy? Why should I use faDirectory or other attributes if the function allways return everything?

As I said, the '.' and '..' *are* directories. Thus, findfirst/findnext should return them.

The function doesn't return everything, but it returns what it is supposed to return. "." is the current "directory", ".." is the parent "directory". They are exactly in the range of entries you have request. They are just two "special" directory entries, and this is the case since DOS 2.0. Just some DOS "compatible" OS have some options to surpress theses special entries (Novell Netware for example).

It shouldn't always return everything, it's returning directories and '.' and '..' ARE directories. If you specify faDirectory, '.' and '..' SHOULD be found as directories. If files are also returned, then you might have a different problem...

Hinrich Donner wrote

Realy? Why should I use faDirectory or other attributes if the function allways return everything?

Hi,

j.urban wrote

It shouldn't always return everything, it's returning directories and '.' and '..' ARE directories. If you specify faDirectory, '.' and '..' SHOULD be found as directories. If files are also returned, then you might have a different problem...

So, if I use

findfirst('*.*',faAnyFile - faDirectory,sr), or, if you mind findfirst('*.*',faAnyFile and not(faDirectory),sr), then, imho, the function should not search for directories. If it does, the declaration of attributes is sensless.

Or is there something wrong in my thougts?

Regards, Hinrich

No, you're right there must be still a bug in findfirst. Michael?

I will have a look.

Michael.

It's fixed. (finally, I hope)

Michael.