Query con SUBSTRING y GROUP BY
 

Necesito ejecutar un query del siguiente estilo contra tablas Paradox para un informe impreso:
El problema me viene en la claúsula GROUP BY. Si lo pongo como está me dice Invalid Field Name refiriéndose al campo Oficina; si pongo en su lugar SUBSTRING(Iban FROM 5 FOR 8) me dice Capability not supported.

Otra alternativa que había pensado era ordenar por ese trozo del campo, así:
eliminando ese SUBSTRING del SELECT, pero entonces me dice Invalid use of keyword.

¿Alguna sugerencia?

Hola Angel.Matilla.

Las bases de datos locales como Paradox o dBASE no soportan el uso de la declaración GROUP BY sobre valores calculados.

No soy experto en estas BD's pero si la agrupación dependiese de una condición podrías usar la cláusula UNION para lograrlo, por ejemplo:

Código SQL [-]
SELECT NOMBRE, DIRECCION FROM TB_CLIENTES
WHERE SUBSTRING(NOMBRE FROM 2 FOR 1) = 'a'
UNION ALL
SELECT NOMBRE, DIRECCION FROM TB_CLIENTES
WHERE SUBSTRING(NOMBRE FROM 2 FOR 1) = 'a'

Pero al menos yo, no veo como aplicarlo a tu caso...

Mi consejo es que abandones las obsoletas bases de datos de escritorio y te vuelques a algo mas poderoso y que te dé menos quebraderos de cabeza.
Aunque hay otras igualmente buenas, Firebird es una excelente opción; es sencillo de configurar, altamente estandarizado y sin lugar a dudas muy poderoso. El requerimiento de mantención es despreciable y particularmente no he tenido fallos por años y hasta el momento. Para no ser pesado no me explayo mas sobre sus bondades :)

Si en algún momento optas por el cambio (o no), te recomiendo leer estos enlaces:

• Pasando de Paradox a Interbase (Parte 1)
• Pasando de Paradox a Interbase (Parte 2)
• Pasando de Paradox a Interbase (Parte 3)
• Pasando de Paradox a Interbase (Parte 4)
• Pasando de Paradox a Interbase (Parte 5)
• Pasando de Paradox a Interbase (Parte 6)
• Pasando de Paradox a Interbase (Parte 7)

Saludos :)

Muchas gracias por tu respuesta. Intuía que iban por ahí los tiros. Sobre migrar a Firebird, que era mi idea, el cliente se ha negado en redondo.

has probado así ?

Código SQL [-]
SELECT A.Apellidos, A.Nombre, A.Iban, SUBSTRING(Iban FROM 5 FOR 8) Oficina,        COUNT(B.Referencia) RecPte, SUM(B.Importe) ImpPte 
FROM 'Persona.db' A, 'Recibos.db' B
WHERE A.Referencia = B.Referencia 
GROUP BY A.Apellidos, A.Nombre, A.Iban, Oficina 
ORDER BY 4, Iban

el 4 indica el numero de campo

Sí, y tampoco funciona. El probelma es que las tablas Paradox no soportan esa funcionalidad.

Jamás se me ocurrió preguntar a un cliente qué BD quiere que use para resolverle un problema.
Jamás un médico me preguntó qué medicina quiero tomar para curarme una dolencia.
Jamás un mecánico me preguntó qué herramienta usar para reparar el motor de mi coche.
etc...

Pues sí, Casimiro..., pero el médico no te paga cuando vas a consultarlo, ni el mecánico firma un compromiso de pago cuando te contrata..., y el cliente sí. En éste caso se aplica la sabia premisa del póker que dice a la letra "el que paga, manda"...

Por raro que te parezca esto no lo decido yo; quieren un sistema que no requiera tener ni el más mínimo conocimiento ni de máquinas ni de programas. Yo hubiera preferido instalar Firebird o MySql.

Hola Angel,
viendo la consulta, estas tratando de ordenar por entidad bancaria.
A parte del IBAN tienes guardado el BIC / SWIF (a partir del 1 de febrero es obligatorio tener este dato para enviar al cobro los recibos)?
Este codigo los 4 primeros caracteres es la entidad, por lo que ordenando por el BIC, tendrias la ordenacion por entidad

El código BIC sólo es obligatorio en transferencias intracomunitarias no para recibos domiciliados:

Si desde tu aplicación generas ficheros para la norma 19 de cobro de recibos, es uno de los campos obligatoris

Creo que has entendido al revés lo que quiero decir:
Yo le pago al mecánico y no decido qué herramientas usar.
Yo le pago al médico y no decido qué medicinas tomar.

Además, como sabes, firebird es libre y gratis, no le va a costar nada al cliente.

¡Fíjate! Exactamente el mismo argumento que usé yo. El problema de este cliente es que no quiere tener contratado, de la amnera que sea, a nadie para que le mantenga los equipos en todos los aspectos... Y así le pasa: Cada dos por tres está con probelmas que clar está ha de pagar a parte.

He estado repasando la normativa que entra en vigor el 1 de febrero (en la web de la AEB) y el codigo BIC sólo se emplea en el caso de transferencias; si se trata de adeudos por domiciliación (norma CSB 19.14) lo que hay que indicar es el IBAN, y he comprobado los cuadernos de carga en varios sitios (por ejemplo: en Bankia Empresas, páginas 15 a 31 de ese documento) y sólo se hace referencia al IBAN, salvo que se me haya despistado.

Bueno, pues peor para él :rolleyes:

Y mejor para mi: tres de cada cuatro veces lo termino arreglando yo.:)

Mira la pag 19 del pdf
el campo 10 de la linea del reigstro individual obligatorio

Tienes razón. Se me había despistado. No obstante, dado que tengo una tabla de entidades bancarias, el código SWIFT lo puedo guardar en dicha tabla junto a la definición del mismo.

Piensa que el swift indica entidad bancaria y localidad y oficina no se si es mejor guardar este codigo junto al iban

Varias cosas.
1. No voy a ser yo quien discuta las normas.
2. Dado que este código es necesario para que «una transferencia intracomunitaria sujeta al Reglameto 2560/2001 esté sometida a la misma comisión que una nacional de idéntico importe», no acabo de entender que demonios pinta en un adeudo por domiciliación, que tiene un tratamiento diferente a las transferencias.No obstante, y dado que el código SWIFT se rige por esta norma:

Los primeros cuatro caracteres identifican el banco
Los siguientes dos caracteres, el país (usando el código ISO 3166-1 alpha-2)
Los siguientes dos caracteres, la localidad
Los últimos tres caracteres (opcionales) identifican la oficina; se puede utilizar 'XXX' para referirse a la principal
Puede utilizarse una versión abreviada de ocho caracteres. En tal caso se sobreentiende que la oficina es la principal.

Dicho esto tampoco es tan complejo guardar el código genérico de cada entidad (por ejemplo BSCHESMM para el Banco Santander Central Hispano, CECAESMM para Liberbank o CAIXESBB para Caixabank) y calcular las tres posciones OPCIONLES.

Dando vueltas para encontrar la lista de los códigos BIC, a través del Banco de España he encontrado esto:
Lo cual significa que a partir del 1 de febrero de 2014 NO es necesario ese código; lo que me sorprende es que sea obligatorio en algo que entra en vigor precisamente ese día.